From sievers@hilton.rwth-aachen.de Thu Dec 1 22:44:08 2005 From: sievers@hilton.rwth-aachen.de (Daniel Sievers) Date: Thu, 01 Dec 2005 23:44:08 +0100 Subject: [Xorp-users] join messages not sent out (from IGMP to PIM) Message-ID: <438F7CB8.6020400@hilton.rwth-aachen.de> Hi, I have a router running xorp and am trying to receive stream on the local net from an external RP. "show igmp group" does show me the clients as having joined the group. But it does not register with the RP then. "show pim join all" Group Source RP Flags 224.0.0.0 xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx RP Upstream interface (RP): eth1 Upstream MRIB next hop (RP): xxx.xxx.xx.xxx Upstream state: NotJoined Join timer: -1 Joins RP: ... Join state: ... Prune state: ... Prune pending state: ... Could assert WC: ... I am DR: OOO Immediate olist RP: ... Inherited olist SG: ... Inherited olist SG_RPT: ... So xorp does not seem to be sending out join messages via pim. When enabling all traces, I can see the IGMP join and I can see PIM_HELLOs from the RP. I cann not see it sending out join messages via pim. I am using the example config from the website mainly. I have tried configuring the RP statically, but with the same result. Anyhow the RP seems to be recognized correctly. Scope is fine, so is the next hop. What could be the causing problem? Do I have to configure igmp on the local vif only or on both? How about pim, do I need to activate that on the external vif only or on both? Thanks! -Daniel From pavlin@icir.org Fri Dec 2 01:46:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 01 Dec 2005 17:46:24 -0800 Subject: [Xorp-users] join messages not sent out (from IGMP to PIM) In-Reply-To: Message from Daniel Sievers of "Thu, 01 Dec 2005 23:44:08 +0100." <438F7CB8.6020400@hilton.rwth-aachen.de> Message-ID: <200512020146.jB21kOo3081860@possum.icir.org> > I have a router running xorp and am trying to receive stream on the > local net from an external RP. > > "show igmp group" does show me the clients as having joined the group. > But it does not register with the RP then. > > "show pim join all" > Group Source RP Flags > 224.0.0.0 xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx RP > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): xxx.xxx.xx.xxx > Upstream state: NotJoined > Join timer: -1 > Joins RP: ... > Join state: ... > Prune state: ... > Prune pending state: ... > Could assert WC: ... > I am DR: OOO > Immediate olist RP: ... > Inherited olist SG: ... > Inherited olist SG_RPT: ... If this is the only entry in the multicast routing table, then it appears that you don't have any (*,G) entry for your multicast group. This would explain why you don't see PIM Join messages originated by XORP. Can you double-check that the multicast group is not link-local (i.e., it shouldn't be in the range 224.0.0.0 -- 224.0.0.255), and that it indeed is shown by "show igmp group". If the IGMP module sees the group membership, then it is the one to tell PIM about it. If you have enabled the PIM log messages, do you see a PIM log message like "Add membership for (%s, %s) on vif %s" when the first receiver joins the group? > So xorp does not seem to be sending out join messages via pim. > When enabling all traces, I can see the IGMP join and I can see > PIM_HELLOs from the RP. I cann not see it sending out join messages via pim. > > I am using the example config from the website mainly. I have tried > configuring the RP statically, but with the same result. Anyhow the RP > seems to be recognized correctly. Scope is fine, so is the next hop. > > What could be the causing problem? > > Do I have to configure igmp on the local vif only or on both? Typically you should configure IGMP on all interfaces that are running PIM (the special register_vif is an exception). > How about pim, do I need to activate that on the external vif only or on > both? You should configure PIM on all interfaces that are expected to be used in the forwarding process: all potential incoming interfaces and all potential outgoing interfaces. Pavlin From abazh18@gmail.com Mon Dec 5 08:44:26 2005 From: abazh18@gmail.com (abazh) Date: Mon, 5 Dec 2005 15:44:26 +0700 Subject: [Xorp-users] Need help for compiling xorp from current cvs on Linux (IPv6 Multicast) Message-ID: <438279e60512050044p1e1f3b5bmcf2bd1e9543dd0dc@mail.gmail.com> ------=_Part_27952_5321466.1133772266480 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I'm new to xorp, As I follow previous discussion on IPv6 Multicast routing on Iinux, I have tried to patch the linux kernel. I use fedore core 4 with USAGI linux kernel 2.6.14. My problem is when trying to compile xorp it self, I got below errors: Making all in . gmake[3]: Entering directory `/root/xorp/cli' source=3D'cli_client.cc' object=3D'cli_client.lo' libtool=3Dyes \ depfile=3D'.deps/cli_client.Plo' tmpdepfile=3D'.deps/cli_client.TPlo' \ depmode=3Dgcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-alig= n -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo `test -f cli_client.cc || echo './'`cli_client.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -MP -MF .deps/cli_client.TPlo -o cli_client.o ../libproto/proto_node.hh: In member function 'uint32_t ProtoNode::vif_name2vif_index(const std::string&) const': ../libproto/proto_node.hh:727: error: no matching function for call to 'find(std::_Rb_tree_const_iterator, std::allocator >, unsigned int> >&)' gmake[3]: *** [cli_client.lo] Error 1 gmake[3]: Leaving directory `/root/xorp/cli' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/root/xorp/cli' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/root/xorp' gmake: *** [all] Error 2 Thanks in advance for help ------=_Part_27952_5321466.1133772266480 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I'm new to xorp,

As I follow previous discussion on IPv6 Multicast routing on Iinux, I have = tried to patch the linux kernel.
I use fedore core 4 with USAGI linux kernel 2.6.14.

My problem is when trying to compile xorp it self, I got below errors:
Making all in .
gmake[3]: Entering directory `/root/xorp/cli'
source=3D'cli_client.cc' object=3D'cli_client.lo' libtool=3Dyes \
depfile=3D'.deps/cli_client.Plo' tmpdepfile=3D'.deps/cli_client.TPlo' \
depmode=3Dgcc3 /bin/sh ../config/depcomp \
/bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo `test -f cli_client.cc || echo './'`cli_client.cc
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -MP -MF .deps/cli_client.TPlo -o cli_client.o
../libproto/proto_node.hh: In member function 'uint32_t ProtoNode<V>:= :vif_name2vif_index(const std::string&) const':
../libproto/proto_node.hh:727: error: no matching function for call to 'find(std::_Rb_tree_const_iterator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned int> >&)'
gmake[3]: *** [cli_client.lo] Error 1
gmake[3]: Leaving directory `/root/xorp/cli'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/root/xorp/cli'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/root/xorp'
gmake: *** [all] Error 2

Thanks in advance for help

------=_Part_27952_5321466.1133772266480-- From tdurack@gmail.com Mon Dec 5 18:25:37 2005 From: tdurack@gmail.com (Tim Durack) Date: Mon, 5 Dec 2005 13:25:37 -0500 Subject: [Xorp-users] OSPF Failures Message-ID: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com> ------=_Part_2401_6103843.1133807137127 Content-Type: multipart/alternative; boundary="----=_Part_2402_11391249.1133807137127" ------=_Part_2402_11391249.1133807137127 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have created a basic network of four XORP routers, meshed together (gre tunnels built outside of XORP.) All the adjacencies come up, but OSPF is randomly dying with the following error: [ 2005/12/05 13:08:23 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed [ 2005/12/05 13:08:23 INFO xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally killed: ospf4 [ 2005/12/05 13:08:23 WARNING xorp_rtrmgr:4322 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 "ospfv2" does not exist or is not enabled. [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table =3D Redist:ospf [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table =3D Redist:ospf [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table =3D Redist:ospf [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table =3D Redist:ospf Not sure why this is happening. I have attached the configs in case it helps. Tim:> ------=_Part_2402_11391249.1133807137127 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have created a basic network of four XORP routers, meshed together (gre t= unnels built outside of XORP.)
All the adjacencies come up, but OSPF is randomly dying with the following = error:

[ 2005/12/05 13:08:23  FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed
[ 2005/12/05 13:08:23  INFO xorp_rtrmgr:4322 RTRMGR +668 module_manage= r.cc killed ] Module abnormally killed: ospf4
[ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322 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 "ospfv2" does not exist or is not enabled.<= br> [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol= ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol= ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol= ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol= ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf


Not sure why this is happening. I have attached the configs in case it help= s.

Tim:>

------=_Part_2402_11391249.1133807137127-- ------=_Part_2401_6103843.1133807137127 Content-Type: application/octet-stream; name=xen1.config Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen1.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" targetname: "rtrmgr" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } targetname: "fea" } plumbing { rib { targetname: "rib" } } interfaces { interface dummy0 { vif dummy0 { address 10.0.0.1 { prefix-length: 32 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.0.0.5 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.9 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.13 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } targetname: "fea" restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.0.0.1 targetname: "ospfv2" ip-router-alert: false area 0.0.0.0 { interface tun0 { vif tun0 { address 10.0.0.5 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface dummy0 { vif dummy0 { address 10.0.0.1 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.9 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.13 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } area-type: "normal" } } } ------=_Part_2401_6103843.1133807137127 Content-Type: application/octet-stream; name=xen2.config Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen2.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" targetname: "rtrmgr" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } targetname: "fea" } plumbing { rib { targetname: "rib" } } interfaces { interface dummy0 { vif dummy0 { address 10.0.0.2 { prefix-length: 32 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.0.0.6 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.17 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.21 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } targetname: "fea" restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.0.0.2 targetname: "ospfv2" ip-router-alert: false area 0.0.0.0 { interface tun0 { vif tun0 { address 10.0.0.6 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface dummy0 { vif dummy0 { address 10.0.0.2 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.17 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.21 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } area-type: "normal" } } } ------=_Part_2401_6103843.1133807137127 Content-Type: application/octet-stream; name=xen3.config Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen3.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" targetname: "rtrmgr" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } targetname: "fea" } plumbing { rib { targetname: "rib" } } interfaces { interface dummy0 { vif dummy0 { address 10.1.0.1 { prefix-length: 32 disable: false } address 10.1.1.1 { prefix-length: 24 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.1.0.5 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.10 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.18 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } targetname: "fea" restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.1.0.1 targetname: "ospfv2" ip-router-alert: false area 0.0.0.0 { interface dummy0 { vif dummy0 { address 10.1.0.1 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun0 { vif tun0 { address 10.1.0.5 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.10 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.18 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } area-type: "normal" } } bgp { bgp-id: 10.1.0.1 targetname: "bgp" local-as: 65001 peer "10.1.0.2" { as: 65001 peer-port: 179 local-port: 179 local-ip: "10.1.0.1" holdtime: 90 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.1.0.2 } } } ------=_Part_2401_6103843.1133807137127 Content-Type: application/octet-stream; name=xen4.config Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen4.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" targetname: "rtrmgr" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } targetname: "fea" } plumbing { rib { targetname: "rib" } } interfaces { interface dummy0 { vif dummy0 { address 10.1.0.2 { prefix-length: 32 disable: false } address 10.1.2.1 { prefix-length: 24 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.1.0.6 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.14 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.22 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" } targetname: "fea" restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.1.0.2 targetname: "ospfv2" ip-router-alert: false area 0.0.0.0 { interface dummy0 { vif dummy0 { address 10.1.0.2 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun0 { vif tun0 { address 10.1.0.6 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.14 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.22 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 } } link-type: "broadcast" } area-type: "normal" } } bgp { bgp-id: 10.1.0.2 targetname: "bgp" local-as: 65001 peer "10.1.0.1" { as: 65001 peer-port: 179 local-port: 179 local-ip: "10.1.0.2" holdtime: 90 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.1.0.1 } } } ------=_Part_2401_6103843.1133807137127-- From caddisconsulting@yahoo.com Mon Dec 5 19:00:30 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Mon, 5 Dec 2005 12:00:30 -0700 Subject: [Xorp-users] RE: [Xorp-hackers] OSPF Failures In-Reply-To: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com> Message-ID: <200512051900.jB5J0gF5069779@wyvern.icir.org> This is a multi-part message in MIME format. ------=_NextPart_000_02A3_01C5F993.80289860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tim, Take a look at XORP bug 383, your issue looks similar but is for different LSA type, however I think it may have the same root cause. Before the crash did you lose your neighbor adjacency and then reestablish it? Atanu, should a new bug be entered or do you think 383 covers this issue as well? Also Tim, there are a number of known issues with the current OSPF code, it might be worth quickly perusing the bug database to see what you might run into in a test environment. -mike _____ From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Tim Durack Sent: Monday, December 05, 2005 11:26 AM To: xorp-users@xorp.org; xorp-hackers@xorp.org Subject: [Xorp-hackers] OSPF Failures I have created a basic network of four XORP routers, meshed together (gre tunnels built outside of XORP.) All the adjacencies come up, but OSPF is randomly dying with the following error: [ 2005/12/05 13:08:23 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 == _entries.count(area)) failed [ 2005/12/05 13:08:23 INFO xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally killed: ospf4 [ 2005/12/05 13:08:23 WARNING xorp_rtrmgr:4322 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 "ospfv2" does not exist or is not enabled. [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf Not sure why this is happening. I have attached the configs in case it helps. Tim:> ------=_NextPart_000_02A3_01C5F993.80289860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Tim,
 
Take a look at XORP bug 383, your issue looks = similar but=20 is for different LSA type, however I think it may have the same root=20 cause.  Before the crash did you lose your neighbor adjacency and = then=20 reestablish it?  Atanu, should a new bug be entered = or do you=20 think 383 covers this issue as well?
 
Also Tim, there are a number of known issues = with the=20 current OSPF code, it might be worth quickly perusing the bug database = to see=20 what you might run into in a test environment.
 
-mike


From: xorp-hackers-admin@icir.org=20 [mailto:xorp-hackers-admin@icir.org] On Behalf Of Tim=20 Durack
Sent: Monday, December 05, 2005 11:26 AM
To:=20 xorp-users@xorp.org; xorp-hackers@xorp.org
Subject: = [Xorp-hackers]=20 OSPF Failures

I have created a basic network of four XORP routers, meshed = together=20 (gre tunnels built outside of XORP.)
All the adjacencies come up, but = OSPF is=20 randomly dying with the following error:

[ 2005/12/05 = 13:08:23 =20 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion = (0 =3D=3D=20 _entries.count(area)) failed
[ 2005/12/05 13:08:23  INFO=20 xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module = abnormally=20 killed: ospf4
[ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322=20 XrlFinderTarget +406 ../xrl/targets/finder_base.cc = handle_finder_0_2_resolve_xrl=20 ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 = Command=20 failed Target "ospfv2" does not exist or is not enabled.
[ 2005/12/05 = 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 = shutting=20 down -------
OriginTable: ospf
IGP
next table =3D = Redist:ospf
[=20 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for = protocol ospfv2=20 shutting down -------
OriginTable: ospf
IGP
next table =3D=20 Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death = event=20 for protocol ospfv2 shutting down -------
OriginTable: = ospf
IGP
next=20 table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] = Received death=20 event for protocol ospfv2 shutting down -------
OriginTable:=20 ospf
IGP
next table =3D Redist:ospf


Not sure why this = is=20 happening. I have attached the configs in case it=20 helps.

Tim:>

------=_NextPart_000_02A3_01C5F993.80289860-- From tdurack@gmail.com Mon Dec 5 20:16:08 2005 From: tdurack@gmail.com (Tim Durack) Date: Mon, 5 Dec 2005 15:16:08 -0500 Subject: [Xorp-users] Re: [Xorp-hackers] OSPF Failures In-Reply-To: <200512051900.jB5J0g0T069778@wyvern.icir.org> References: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com> <200512051900.jB5J0g0T069778@wyvern.icir.org> Message-ID: <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com> ------=_Part_4188_25978545.1133813768724 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/5/05, Mike Horn wrote: > > Hi Tim, > > Take a look at XORP bug 383, your issue looks similar but is for differen= t > LSA type, however I think it may have the same root cause. Before the cr= ash > did you lose your neighbor adjacency and then reestablish it? Atanu, > should a new bug be entered or do you think 383 covers this issue as well= ? > The adjacency had just been brought up, after starting xorp_rtrmgr and loading the config. It seems to happen randomly to all four of the routers in my lab setup. Also Tim, there are a number of known issues with the current OSPF code, it > might be worth quickly perusing the bug database to see what you might ru= n > into in a test environment. > I know XORP is still very much beta, but it shows a lot of promise. I'm using it in a Xen laptop based router lab, to teach and test various routing protocols and configurations. -mike > > ------------------------------ > *From:* xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] = *On > Behalf Of *Tim Durack > *Sent:* Monday, December 05, 2005 11:26 AM > *To:* xorp-users@xorp.org; xorp-hackers@xorp.org > *Subject:* [Xorp-hackers] OSPF Failures > > I have created a basic network of four XORP routers, meshed together (gre > tunnels built outside of XORP.) > All the adjacencies come up, but OSPF is randomly dying with the followin= g > error: > > [ 2005/12/05 13:08:23 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc > add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed > [ 2005/12/05 13:08:23 INFO xorp_rtrmgr:4322 RTRMGR +668 module_manager.c= c > killed ] Module abnormally killed: ospf4 > [ 2005/12/05 13:08:23 WARNING xorp_rtrmgr:4322 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 "ospfv2" does not exist or is not enabled. > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > protocol ospfv2 shutting down ------- > OriginTable: ospf > IGP > next table =3D Redist:ospf > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > protocol ospfv2 shutting down ------- > OriginTable: ospf > IGP > next table =3D Redist:ospf > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > protocol ospfv2 shutting down ------- > OriginTable: ospf > IGP > next table =3D Redist:ospf > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > protocol ospfv2 shutting down ------- > OriginTable: ospf > IGP > next table =3D Redist:ospf > > > Not sure why this is happening. I have attached the configs in case it > helps. > > Tim:> > > ------=_Part_4188_25978545.1133813768724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/5/05, Mike Horn <caddisconsulting@yahoo.com> wrote:
Hi Tim,
 
Take a look at XORP bug 383, your issue looks similar but=20 is for different LSA type, however I think it may have the same root=20 cause.  Before the crash did you lose your neighbor adjacency and then= =20 reestablish it?  Atanu, should a new bug be entered or do you=20 think 383 covers this issue as well?

The adjacency had just been brought up, after starting xorp_rtrmgr and load= ing the config.
It seems to happen randomly to all four of the routers in my lab setup.

Also Tim, there are a number of known issues with the=20 current OSPF code, it might be worth quickly perusing the bug database to s= ee=20 what you might run into in a test environment.

I know XORP is still very much beta, but it shows a lot of promise.
I'm using it in a Xen laptop based router lab, to teach and test various ro= uting protocols and configurations.

-mike


From: xorp-hackers-admin@icir.org=20 [mailto:xorp-hackers-admin@i= cir.org] On Behalf Of Tim=20 Durack
Sent: Monday, December 05, 2005 11:26 AM
To:=20 xorp-users@xorp.org; xorp-hackers@xorp.org
Subject: [Xorp-hackers]=20 OSPF Failures

I have= created a basic network of four XORP routers, meshed together=20 (gre tunnels built outside of XORP.)
All the adjacencies come up, but OS= PF is=20 randomly dying with the following error:

[ 2005/12/05 13:08:23 = =20 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 = =3D=3D=20 _entries.count(area)) failed
[ 2005/12/05 13:08:23  INFO=20 xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally= =20 killed: ospf4
[ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322=20 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv= e_xrl=20 ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Comman= d=20 failed Target "ospfv2" does not exist or is not enabled.
[ 200= 5/12/05=20 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutt= ing=20 down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[= =20 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol o= spfv2=20 shutting down -------
OriginTable: ospf
IGP
next table =3D=20 Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death eve= nt=20 for protocol ospfv2 shutting down -------
OriginTable: ospf
IGP
ne= xt=20 table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received= death=20 event for protocol ospfv2 shutting down -------
OriginTable:=20 ospf
IGP
next table =3D Redist:ospf


Not sure why this is= =20 happening. I have attached the configs in case it=20 helps.

Tim:>


------=_Part_4188_25978545.1133813768724-- From pusateri@bangj.com Mon Dec 5 23:37:59 2005 From: pusateri@bangj.com (Tom Pusateri) Date: Mon, 05 Dec 2005 18:37:59 -0500 Subject: [Xorp-users] IGMP/PIM cannot send packets on FreeBSD 5.3 Message-ID: <20051205233800.2E28CB830@jj.bangj.com> I'm sure I must be doing something silly here but I've got a FreeBSD 5.3 system compiled with options MROUTING and options PIM and I've built the latest xorp from CVS from two days ago. [ 2005/12/05 18:23:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/ 0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send IG MP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 [ 2005/12/05 18:23:27 ERROR xorp_igmp:612 MLD6IGMP +1516 xrl_mld6igmp_node.cc m fea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Comman d failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 Anyone got any ideas? Thanks, Tom My config file looks like this: gw# cat config.boot interfaces { interface fxp0 { description: "Time Warner Cable interface" disable: false default-system-config } interface fxp1 { description: "home public network" disable: false default-system-config } interface gre0 { description: "tunnel to nc state" disable: false default-system-config } } protocols { static { route4 0.0.0.0/0 { next-hop: 10.14.12.141 metric: 1 } } igmp { disable: false interface fxp1 { vif fxp1 { disable: false } } traceoptions { flag all { disable: false } } } pimsm4 { disable: false interface fxp1 { vif fxp1 { disable: false } } interface gre0 { vif gre0 { disable: false } } static-rps { rp 10.1.255.115 { group-prefix 224.0.0.0/4 { } } } bootstrap { disable: true } traceoptions { flag all { disable: false } } } } And here is the log messages from running xorp: gw# ./xorp_rtrmgr -b config.boot [ 2005/12/05 18:23:16 INFO xorp_rtrmgr:609 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, igmp, pimsm4, policy, static_routes [ 2005/12/05 18:23:16 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: interfaces (/usr/local/xorp/fea/xorp_fea) [ 2005/12/05 18:23:16 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard interface. [ 2005/12/05 18:23:16 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard interface. [ 2005/12/05 18:23:16 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard interface. [ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] MFEA enabled [ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI enabled [ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI started [ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] MFEA enabled [ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI enabled [ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI started [ 2005/12/05 18:23:18 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: fea (/usr/local/xorp/fea/xorp_fea) [ 2005/12/05 18:23:22 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: mfea4 (/usr/local/xorp/fea/xorp_fea) [ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] Interface added: Vif[fxp0] pif_index: 1 vif_index: 0 addr: 10.11.250.52 subnet: 10.11.248.0/21 broadcast: 255.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] Interface added: Vif[fxp1] pif_index: 2 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] Interface added: Vif[gre0] pif_index: 5 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] MFEA started [ 2005/12/05 18:23:23 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: rib (/usr/local/xorp/rib/xorp_rib) [ 2005/12/05 18:23:25 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: igmp (/usr/local/xorp/mld6igmp/xorp_igmp) [ 2005/12/05 18:23:25 WARNING xorp_rtrmgr:609 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 "IGMP" does not exist or is not enabled. [ 2005/12/05 18:23:25 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2005/12/05 18:23:25 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2005/12/05 18:23:25 INFO xorp_igmp MLD6IGMP ] CLI started [ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[fxp0] pif_index: 0 vif_index: 0 addr: 10.11.250.52 subnet: 10.11.248.0/21 broadcast: 255.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[gre0] pif_index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2005/12/05 18:23:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2005/12/05 18:23:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2005/12/05 18:23:27 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: pimsm4 (/usr/local/xorp/pim/xorp_pimsm4) [ 2005/12/05 18:23:27 WARNING xorp_rtrmgr:609 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 "PIMSM_4" does not exist or is not enabled. [ 2005/12/05 18:23:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 [ 2005/12/05 18:23:27 ERROR xorp_igmp:612 MLD6IGMP +1516 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 [ 2005/12/05 18:23:28 WARNING xorp_rtrmgr:609 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 Xrl target is not enabled. [ 2005/12/05 18:23:29 INFO xorp_pimsm4 PIM ] Protocol enabled [ 2005/12/05 18:23:29 INFO xorp_pimsm4 PIM ] CLI enabled [ 2005/12/05 18:23:29 INFO xorp_pimsm4 PIM ] CLI started [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface added: Vif[fxp0] pif_index: 0 vif_index: 0 addr: 10.11.250.52 subnet: 10.11.248.0/21 broadcast: 255.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface added: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface added: Vif[gre0] pif_index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Protocol started [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface started: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[gre0] pif_index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2005/12/05 18:23:31 INFO xorp_pimsm4 PIM ] Interface started: Vif[gre0] pif_index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2005/12/05 18:23:31 INFO xorp_pimsm4 PIM ] Bootstrap mechanism disabled [ 2005/12/05 18:23:31 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: policy (/usr/local/xorp/policy/xorp_policy) [ 2005/12/05 18:23:33 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run ] Running module: static_routes (/usr/local/xorp/static_routes/xorp_static_routes) [ 2005/12/05 18:23:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:23:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:23:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:23:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:23:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:23:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:23:35 INFO xorp_rtrmgr:609 RTRMGR +2229 task.cc run_task ] No more tasks to run [ 2005/12/05 18:23:35 ERROR xorp_fea:610 FEA +366 fticonfig_entry_set_rtsock.cc add_entry ] Error writing to routing socket: File exists [ 2005/12/05 18:23:35 ERROR xorp_fea:610 FEA +71 fti_transaction.cc operation_result ] FTI transaction commit failed on AddEntry4: net = 0.0.0.0/0 nexthop = 10.14.12.141 ifname = gre0 vifname = gre0 metric = 1 admin_distance = 1 xorp_route = true is_deleted = false is_unresolved = false is_connected_route = false [ 2005/12/05 18:23:35 WARNING xorp_fea XrlFeaTarget ] Handling method for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 Command failed AddEntry4: net = 0.0.0.0/0 nexthop = 10.14.12.141 ifname = gre0 vifname = gre0 metric = 1 admin_distance = 1 xorp_route = true is_deleted = false is_unresolved = false is_connected_route = false [ 2005/12/05 18:23:35 ERROR xorp_rib:611 RIB +907 redist_xrl.cc dispatch_complete ] Failed to commit transaction: 102 Command failed AddEntry4: net = 0.0.0.0/0 nexthop = 10.14.12.141 ifname = gre0 vifname = gre0 metric = 1 admin_distance = 1 xorp_route = true is_deleted = false is_unresolved = false is_connected_route = false [ 2005/12/05 18:23:59 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.14.12.177 to 224.0.0.1 [ 2005/12/05 18:23:59 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 [ 2005/12/05 18:23:59 ERROR xorp_igmp:612 MLD6IGMP +1516 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 [ 2005/12/05 18:24:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:24:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:24:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:24:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:24:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:24:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:24:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:24:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:24:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:24:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:24:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:24:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 ^C[ 2005/12/05 18:25:29 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: static_routes [ 2005/12/05 18:25:29 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc normal_exit ] Module normal exit: static_routes [ 2005/12/05 18:25:29 ERROR xorp_rtrmgr:609 LIBXORP +414 asyncio.cc complete_transfer ] Write error 32 [ 2005/12/05 18:25:30 WARNING xorp_rtrmgr:609 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 "static_routes" does not exist or is not enabled. [ 2005/12/05 18:25:31 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: policy [ 2005/12/05 18:25:31 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc normal_exit ] Module normal exit: policy [ 2005/12/05 18:25:31 INFO xorp_rtrmgr:609 XRL +391 xrl_router.cc send_resolved ] Sender died (protocol = "stcp", address = "127.0.0.1:62288") [ 2005/12/05 18:25:31 ERROR xorp_rtrmgr:609 LIBXORP +211 buffered_asyncio.cc io_event ] read error 61 [ 2005/12/05 18:25:31 ERROR xorp_rtrmgr:609 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 61) [ 2005/12/05 18:25:31 ERROR xorp_rtrmgr:609 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error [ 2005/12/05 18:25:32 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: pimsm4 [ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] CLI stopped [ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[gre0] pif_index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 [ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface deleted: fxp0 [ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface deleted: fxp1 [ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface deleted: gre0 [ 2005/12/05 18:25:32 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc normal_exit ] Module normal exit: pimsm4 [ 2005/12/05 18:25:33 WARNING xorp_rtrmgr:609 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 "PIMSM_4" does not exist or is not enabled. [ 2005/12/05 18:25:34 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: igmp [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] CLI stopped [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface stopped: Vif[fxp1] pif_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] CLI stopped [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] CLI stopped [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface deleted: fxp0 [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface deleted: fxp1 [ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface deleted: gre0 [ 2005/12/05 18:25:34 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc normal_exit ] Module normal exit: igmp [ 2005/12/05 18:25:35 WARNING xorp_rtrmgr:609 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 "IGMP" does not exist or is not enabled. [ 2005/12/05 18:25:36 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: rib [ 2005/12/05 18:25:36 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc normal_exit ] Module normal exit: rib [ 2005/12/05 18:25:37 WARNING xorp_rtrmgr:609 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 "rib" does not exist or is not enabled. [ 2005/12/05 18:25:38 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: mfea4 [ 2005/12/05 18:25:38 INFO xorp_fea MFEA ] CLI stopped [ 2005/12/05 18:25:39 INFO xorp_rtrmgr:609 RTRMGR +247 module_manager.cc terminate ] Terminating module: mfea4 [ 2005/12/05 18:25:42 INFO xorp_rtrmgr:609 RTRMGR +247 module_manager.cc terminate ] Terminating module: fea [ 2005/12/05 18:25:42 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Shutting down module: interfaces [ 2005/12/05 18:25:42 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard interface. [ 2005/12/05 18:25:42 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard interface. [ 2005/12/05 18:25:42 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard interface. [ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] CLI stopped [ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] Interface deleted: fxp0 [ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] Interface deleted: fxp1 [ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] Interface deleted: gre0 [ 2005/12/05 18:25:42 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc normal_exit ] Module normal exit: interfaces [ 2005/12/05 18:25:43 INFO xorp_rtrmgr:609 RTRMGR +2229 task.cc run_task ] No more tasks to run gw# From pusateri@bangj.com Tue Dec 6 00:14:16 2005 From: pusateri@bangj.com (Tom Pusateri) Date: Mon, 05 Dec 2005 19:14:16 -0500 Subject: [Xorp-users] IGMP/PIM cannot send packets on FreeBSD 5.3 In-Reply-To: Message from Tom Pusateri of "Mon, 05 Dec 2005 18:37:59 EST." <20051205233800.2E28CB830@jj.bangj.com> Message-ID: <20051206001416.291FDB830@jj.bangj.com> Never mind... I figured it out. I forgot to include the plumbing section in my config. Thanks, Tom In message <20051205233800.2E28CB830@jj.bangj.com> you write: >I'm sure I must be doing something silly here but I've got a FreeBSD 5.3 >system compiled with options MROUTING and options PIM and I've built >the latest xorp from CVS from two days ago. > >[ 2005/12/05 18:23:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/ >0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send >IG >MP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 >[ 2005/12/05 18:23:27 ERROR xorp_igmp:612 MLD6IGMP +1516 xrl_mld6igmp_node.cc > m >fea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Comm >an >d failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 on v >if > fxp1 > >Anyone got any ideas? > >Thanks, >Tom > >My config file looks like this: > >gw# cat config.boot >interfaces { > interface fxp0 { > description: "Time Warner Cable interface" > disable: false > default-system-config > } > interface fxp1 { > description: "home public network" > disable: false > default-system-config > } > interface gre0 { > description: "tunnel to nc state" > disable: false > default-system-config > } >} > >protocols { > static { > route4 0.0.0.0/0 { > next-hop: 10.14.12.141 > metric: 1 > } > } > > igmp { > disable: false > interface fxp1 { > vif fxp1 { > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > > pimsm4 { > disable: false > interface fxp1 { > vif fxp1 { > disable: false > } > } > interface gre0 { > vif gre0 { > disable: false > } > } > static-rps { > rp 10.1.255.115 { > group-prefix 224.0.0.0/4 { > } > } > } > bootstrap { > disable: true > } > traceoptions { > flag all { > disable: false > } > } > } >} > >And here is the log messages from running xorp: > >gw# ./xorp_rtrmgr -b config.boot >[ 2005/12/05 18:23:16 INFO xorp_rtrmgr:609 RTRMGR +240 master_conf_tree.cc ex >ecute ] Changed modules: interfaces, fea, mfea4, rib, igmp, pimsm4, policy, st >atic_routes >[ 2005/12/05 18:23:16 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: interfaces (/usr/local/xorp/fea/xorp_fea) >[ 2005/12/05 18:23:16 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm >_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard inter >face. >[ 2005/12/05 18:23:16 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm >_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard inter >face. >[ 2005/12/05 18:23:16 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm >_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard inter >face. >[ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] MFEA enabled >[ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI enabled >[ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI started >[ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] MFEA enabled >[ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI enabled >[ 2005/12/05 18:23:18 INFO xorp_fea MFEA ] CLI started >[ 2005/12/05 18:23:18 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: fea (/usr/local/xorp/fea/xorp_fea) >[ 2005/12/05 18:23:22 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: mfea4 (/usr/local/xorp/fea/xorp_fea) >[ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] Interface added: Vif[fxp0] pif_inde >x: 1 vif_index: 0 addr: 10.11.250.52 subnet: 10.11.248.0/21 broadcast: 255.255 >.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] Interface added: Vif[fxp1] pif_inde >x: 2 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.14. >12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] Interface added: Vif[gre0] pif_inde >x: 5 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0.0. >0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:23 INFO xorp_fea MFEA ] MFEA started >[ 2005/12/05 18:23:23 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: rib (/usr/local/xorp/rib/xorp_rib) >[ 2005/12/05 18:23:25 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: igmp (/usr/local/xorp/mld6igmp/xorp_igmp) >[ 2005/12/05 18:23:25 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "IGMP" does not > exist or is not enabled. >[ 2005/12/05 18:23:25 INFO xorp_igmp MLD6IGMP ] Protocol enabled >[ 2005/12/05 18:23:25 INFO xorp_igmp MLD6IGMP ] CLI enabled >[ 2005/12/05 18:23:25 INFO xorp_igmp MLD6IGMP ] CLI started >[ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[fxp0] pif >_index: 0 vif_index: 0 addr: 10.11.250.52 subnet: 10.11.248.0/21 broadcast: 25 >5.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[fxp1] pif >_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 1 >0.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[gre0] pif >_index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0 >.0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:26 INFO xorp_igmp MLD6IGMP ] Protocol started >[ 2005/12/05 18:23:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[fxp1] p >if_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: > 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN >IPv4 ENABLED >[ 2005/12/05 18:23:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[fxp1] p >if_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: > 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IP >v4 ENABLED >[ 2005/12/05 18:23:27 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: pimsm4 (/usr/local/xorp/pim/xorp_pimsm4) >[ 2005/12/05 18:23:27 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_4" does >not exist or is not enabled. >[ 2005/12/05 18:23:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 >[ 2005/12/05 18:23:27 ERROR xorp_igmp:612 MLD6IGMP +1516 xrl_mld6igmp_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Co >mmand failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 >on vif fxp1 >[ 2005/12/05 18:23:28 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Xrl target is not enab >led. >[ 2005/12/05 18:23:29 INFO xorp_pimsm4 PIM ] Protocol enabled >[ 2005/12/05 18:23:29 INFO xorp_pimsm4 PIM ] CLI enabled >[ 2005/12/05 18:23:29 INFO xorp_pimsm4 PIM ] CLI started >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface added: Vif[fxp0] pif_in >dex: 0 vif_index: 0 addr: 10.11.250.52 subnet: 10.11.248.0/21 broadcast: 255.2 >55.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface added: Vif[fxp1] pif_in >dex: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10.1 >4.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface added: Vif[gre0] pif_in >dex: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0.0. >0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Protocol started >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[fxp1] pif_ >index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10 >.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv >4 ENABLED >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface started: Vif[fxp1] pif_ >index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10 >.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 >ENABLED >[ 2005/12/05 18:23:30 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[gre0] pif_ >index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0. >0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP DOWN IPv4 ENAB >LED >[ 2005/12/05 18:23:31 INFO xorp_pimsm4 PIM ] Interface started: Vif[gre0] pif_ >index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0. >0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP UP IPv4 ENABLE >D >[ 2005/12/05 18:23:31 INFO xorp_pimsm4 PIM ] Bootstrap mechanism disabled >[ 2005/12/05 18:23:31 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: policy (/usr/local/xorp/policy/xorp_policy) >[ 2005/12/05 18:23:33 INFO xorp_rtrmgr:609 RTRMGR +484 module_manager.cc run >] Running module: static_routes (/usr/local/xorp/static_routes/xorp_static_rou >tes) >[ 2005/12/05 18:23:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 t >o 224.0.0.13 on vif gre0 >[ 2005/12/05 18:23:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 >[ 2005/12/05 18:23:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on v >if gre0 >[ 2005/12/05 18:23:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 t >o 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:23:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:23:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on v >if fxp1 >[ 2005/12/05 18:23:35 INFO xorp_rtrmgr:609 RTRMGR +2229 task.cc run_task ] No > more tasks to run >[ 2005/12/05 18:23:35 ERROR xorp_fea:610 FEA +366 fticonfig_entry_set_rtsock. >cc add_entry ] Error writing to routing socket: File exists >[ 2005/12/05 18:23:35 ERROR xorp_fea:610 FEA +71 fti_transaction.cc operation >_result ] FTI transaction commit failed on AddEntry4: net = 0.0.0.0/0 nexthop >= 10.14.12.141 ifname = gre0 vifname = gre0 metric = 1 admin_distance = 1 xorp >_route = true is_deleted = false is_unresolved = false is_connected_route = fa >lse >[ 2005/12/05 18:23:35 WARNING xorp_fea XrlFeaTarget ] Handling method for redi >st_transaction4/0.1/commit_transaction failed: XrlCmdError 102 Command failed >AddEntry4: net = 0.0.0.0/0 nexthop = 10.14.12.141 ifname = gre0 vifname = gre0 > metric = 1 admin_distance = 1 xorp_route = true is_deleted = false is_unresol >ved = false is_connected_route = false >[ 2005/12/05 18:23:35 ERROR xorp_rib:611 RIB +907 redist_xrl.cc dispatch_comp >lete ] Failed to commit transaction: 102 Command failed AddEntry4: net = 0.0.0 >.0/0 nexthop = 10.14.12.141 ifname = gre0 vifname = gre0 metric = 1 admin_dist >ance = 1 xorp_route = true is_deleted = false is_unresolved = false is_connect >ed_route = false >[ 2005/12/05 18:23:59 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from > 10.14.12.177 to 224.0.0.1 >[ 2005/12/05 18:23:59 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d IGMP protocol message from 10.14.12.177 to 224.0.0.1 on vif fxp1 >[ 2005/12/05 18:23:59 ERROR xorp_igmp:612 MLD6IGMP +1516 xrl_mld6igmp_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Co >mmand failed Cannot send IGMP protocol message from 10.14.12.177 to 224.0.0.1 >on vif fxp1 >[ 2005/12/05 18:24:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 t >o 224.0.0.13 on vif gre0 >[ 2005/12/05 18:24:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 >[ 2005/12/05 18:24:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on v >if gre0 >[ 2005/12/05 18:24:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 t >o 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:24:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:24:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on v >if fxp1 >[ 2005/12/05 18:24:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 t >o 224.0.0.13 on vif gre0 >[ 2005/12/05 18:24:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 >[ 2005/12/05 18:24:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on v >if gre0 >[ 2005/12/05 18:24:33 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 t >o 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:24:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:24:33 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on v >if fxp1 >[ 2005/12/05 18:25:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 t >o 224.0.0.13 on vif gre0 >[ 2005/12/05 18:25:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 [ 2005/12/05 18:25:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cli >ent_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fai >led Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vi >f gre0 >[ 2005/12/05 18:25:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 t >o 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:25:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:25:03 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on v >if fxp1 >^C[ 2005/12/05 18:25:29 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] >Shutting down module: static_routes >[ 2005/12/05 18:25:29 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc norm >al_exit ] Module normal exit: static_routes >[ 2005/12/05 18:25:29 ERROR xorp_rtrmgr:609 LIBXORP +414 asyncio.cc complete_ >transfer ] Write error 32 >[ 2005/12/05 18:25:30 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "static_routes" > does not exist or is not enabled. >[ 2005/12/05 18:25:31 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Sh >utting down module: policy >[ 2005/12/05 18:25:31 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc norm >al_exit ] Module normal exit: policy >[ 2005/12/05 18:25:31 INFO xorp_rtrmgr:609 XRL +391 xrl_router.cc send_resolv >ed ] Sender died (protocol = "stcp", address = "127.0.0.1:62288") >[ 2005/12/05 18:25:31 ERROR xorp_rtrmgr:609 LIBXORP +211 buffered_asyncio.cc >io_event ] read error 61 >[ 2005/12/05 18:25:31 ERROR xorp_rtrmgr:609 XRL +783 xrl_pf_stcp.cc read_even >t ] Read failed (error = 61) >[ 2005/12/05 18:25:31 ERROR xorp_rtrmgr:609 XRL +636 xrl_pf_stcp.cc die ] Xrl >PFSTCPSender died: read error >[ 2005/12/05 18:25:32 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Sh >utting down module: pimsm4 >[ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] CLI stopped >[ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 t >o 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 t >o 224.0.0.13 on vif gre0 >[ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.177 t >o 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[fxp1] pif_ >index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: 10 >.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv >4 ENABLED >[ 2005/12/05 18:25:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.14.12.142 t >o 224.0.0.13 on vif gre0 >[ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[gre0] pif_ >index: 0 vif_index: 2 addr: 10.14.12.142 subnet: 10.14.12.142/32 broadcast: 0. >0.0.0 peer: 10.14.12.141 Flags: P2P MULTICAST UNDERLYING_VIF_UP DOWN IPv4 ENAB >LED >[ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on v >if fxp1 >[ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 >[ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on v >if gre0 >[ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on vif fxp1 >[ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.177 to 224.0.0.13 on v >if fxp1 >[ 2005/12/05 18:25:32 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfe >a/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot sen >d PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on vif gre0 >[ 2005/12/05 18:25:32 ERROR xorp_pimsm4:613 PIM +2618 xrl_pim_node.cc mfea_cl >ient_send_protocol_message_cb ] Cannot send a protocol message: 102 Command fa >iled Cannot send PIMSM_4 protocol message from 10.14.12.142 to 224.0.0.13 on v >if gre0 >[ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface deleted: fxp0 >[ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface deleted: fxp1 >[ 2005/12/05 18:25:32 INFO xorp_pimsm4 PIM ] Interface deleted: gre0 >[ 2005/12/05 18:25:32 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc norm >al_exit ] Module normal exit: pimsm4 >[ 2005/12/05 18:25:33 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_4" does >not exist or is not enabled. >[ 2005/12/05 18:25:34 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Sh >utting down module: igmp >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] CLI stopped >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface stopped: Vif[fxp1] p >if_index: 0 vif_index: 1 addr: 10.14.12.177 subnet: 10.14.12.176/28 broadcast: > 10.14.12.191 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN >IPv4 ENABLED >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] CLI stopped >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] CLI stopped >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface deleted: fxp0 >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface deleted: fxp1 >[ 2005/12/05 18:25:34 INFO xorp_igmp MLD6IGMP ] Interface deleted: gre0 >[ 2005/12/05 18:25:34 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc norm >al_exit ] Module normal exit: igmp >[ 2005/12/05 18:25:35 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "IGMP" does not > exist or is not enabled. >[ 2005/12/05 18:25:36 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Sh >utting down module: rib >[ 2005/12/05 18:25:36 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc norm >al_exit ] Module normal exit: rib >[ 2005/12/05 18:25:37 WARNING xorp_rtrmgr:609 XrlFinderTarget +406 ../xrl/tar >gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder >/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not >exist or is not enabled. >[ 2005/12/05 18:25:38 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Sh >utting down module: mfea4 >[ 2005/12/05 18:25:38 INFO xorp_fea MFEA ] CLI stopped >[ 2005/12/05 18:25:39 INFO xorp_rtrmgr:609 RTRMGR +247 module_manager.cc term >inate ] Terminating module: mfea4 >[ 2005/12/05 18:25:42 INFO xorp_rtrmgr:609 RTRMGR +247 module_manager.cc term >inate ] Terminating module: fea >[ 2005/12/05 18:25:42 INFO xorp_rtrmgr:609 RTRMGR +1019 task.cc shutdown ] Sh >utting down module: interfaces >[ 2005/12/05 18:25:42 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm >_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard inter >face. >[ 2005/12/05 18:25:42 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm >_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard inter >face. >[ 2005/12/05 18:25:42 ERROR xorp_fea:610 FEA +431 routing_socket_utils.cc rtm >_get_to_fte_cfg ] Cannot map a discard route back to an FEA soft discard inter >face. >[ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] CLI stopped >[ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] Interface deleted: fxp0 >[ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] Interface deleted: fxp1 >[ 2005/12/05 18:25:42 INFO xorp_fea MFEA ] Interface deleted: gre0 >[ 2005/12/05 18:25:42 INFO xorp_rtrmgr:609 RTRMGR +642 module_manager.cc norm >al_exit ] Module normal exit: interfaces >[ 2005/12/05 18:25:43 INFO xorp_rtrmgr:609 RTRMGR +2229 task.cc run_task ] No > more tasks to run >gw# > >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pusateri@bangj.com Tue Dec 6 04:13:15 2005 From: pusateri@bangj.com (Tom Pusateri) Date: Mon, 05 Dec 2005 23:13:15 -0500 Subject: [Xorp-users] retaining static routes Message-ID: <20051206041315.75774B830@jj.bangj.com> Is there a way to retain static routes when xorp terminates? if they were in before xorp started, it would be nice if it would leave them in. Or have a flag to not remove them. Thanks, Tom From atanu@ICSI.Berkeley.EDU Tue Dec 6 05:56:29 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 05 Dec 2005 21:56:29 -0800 Subject: [Xorp-users] retaining static routes In-Reply-To: Message from Tom Pusateri of "Mon, 05 Dec 2005 23:13:15 EST." <20051206041315.75774B830@jj.bangj.com> Message-ID: <73462.1133848589@tigger.icir.org> Hi, XORP attempts to mark routes that is adds to the kernel, on FreeBSD it marks them with RTF_PROTO1. When XORP shuts down it should only removed the marked routes. If XORP is removing routes that were already present and unmarked this is a bug. I just tried a simple experiment on FreeBSD 6.0, I added a static route, started XORP, then killed it, the route was still there. XORP routing protocols will on shutdown attempt to remove all the routes that they have installed. If for example XORP is configured with a static route that already existed before XORP was started the route will be removed. The only way around this would be to take a snapshot of the routing table on startup and put it back on shutdown. A flag already exists for interfaces were the original config can be put back on shutdown. We should perhaps consider a similar option for the routing table. Atanu. >>>>> "Tom" == Tom Pusateri writes: Tom> Is there a way to retain static routes when xorp terminates? Tom> if they were in before xorp started, it would be nice if it Tom> would leave them in. Or have a flag to not remove them. Tom> Thanks, Tom Tom> _______________________________________________ Xorp-users Tom> mailing list Xorp-users@xorp.org Tom> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From feamster@lcs.mit.edu Tue Dec 6 22:34:06 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Tue, 6 Dec 2005 17:34:06 -0500 Subject: [Xorp-users] "No Finder" error message? Message-ID: <20051206223404.GK30316@lcs.mit.edu> Hi again, Can you advise why XORP may be crashing on the following error message? [ 2005/12/06 17:29:46 ERROR xorp_rtrmgr:27933 XRL +634 xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? Thanks! Nick From wumingqu@gmail.com Wed Dec 7 19:12:32 2005 From: wumingqu@gmail.com (Mingquan Wu) Date: Wed, 7 Dec 2005 14:12:32 -0500 Subject: [Xorp-users] can not find RP in PIM-SM Message-ID: <52b73ec80512071112r565098d4j9483927ee6065ce9@mail.gmail.com> ------=_Part_841_31610218.1133982752890 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I tried to configure a linux box as a multicast router using xorp, and als= o use it as BST server and RP. Then I have a source (on the same machine) sen= d multicast packets to a multicast address, say 224.1.2.3, the router add the source as a group member but warns that the group 224.1.2.3 does not have a RP. the following is my configure file, thanks in advance. interfaces { interface eth0 { disable: false default-system-config } interface eth1 { disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: "192.168.71.49" */ /* bsr-priority: 1 */ } } cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 192.168.71.49 */ /* rp-priority: 1 */ /* rp-holdtime: 150 */ } } } switch-to-spt-threshold { disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } ------=_Part_841_31610218.1133982752890 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I tried to configure a linux box as a multicast router using xorp,  and also use it as BST server and RP. Then I have a source (on the same machine) send multicast packets to a multicast address, say  224.1.2.3,  the router = ; add the source as a group member but warns that the group 224.1.2.3 = does not have a RP. the following is my configure file, thanks in advance.

interfaces {
    interface eth0 {
        disable: false
        default-system-config
    }
    interface eth1 {
        disable: false
        default-system-config
    }
}

fea {
        unicast-forwarding4 {
    disable: false
    }
}

plumbing {
    mfea4 {
        disable: false
        interface eth0 {
            vif eth0= {
            &nb= sp;   disable: false
            }
        }
        interface eth1 {
            vif eth1= {
            &nb= sp;   disable: false
            }
        }
        interface register_vif {
            vif regi= ster_vif {
            &nb= sp;   /* Note: this vif should be always enabled */
            &nb= sp;   disable: false
            }
        }
        traceoptions {
            flag all= {
            &nb= sp;   disable: false
            }
        }
    }
}

protocols {
    igmp {
        disable: false
        interface eth0 {
            vif eth0= {
            &nb= sp;   disable: false
            }
        }
        interface eth1 {
            vif eth1= {
            &nb= sp;   disable: false
            }
        }
        traceoptions {
            flag all= {
            &nb= sp;   disable: false
            }
        }
    }
}

protocols {
    pimsm4 {
        disable: false
        interface eth0 {
            vif eth0= {
            &nb= sp;   disable: false
            }
        }
        interface eth1 {
            vif eth1= {
            &nb= sp;   disable: false
            }
        }
        interface register_vif {
            vif regi= ster_vif {
            &nb= sp;   /* Note: this vif should be always enabled */
            &nb= sp;   disable: false
            }
        }

        bootstrap {
            disable:= false
            cand-bsr= {
            &nb= sp;   scope-zone 224.0.0.0/4 {=
            &nb= sp;      cand-bsr-by-vif-name: "eth0"
           /* cand-bsr-by-vif-addr:= "192.168.71.49" */
            &nb= sp;       /* bsr-priority: 1 */
            &nb= sp;   }
            }

            cand-rp = {
            &nb= sp;   group-prefix 224.0.0.0/4= {
            &nb= sp;       cand-rp-by-vif-name: "eth0"
            &nb= sp;      /* cand-rp-by-vif-addr: 192.168.71.49 = */
            &nb= sp;      /*  rp-priority: 1 */
            &nb= sp;      /* rp-holdtime: 150 */
            &nb= sp;   }
            }
        }
     switch-to-spt-threshold {
             di= sable: false
             in= terval-sec: 100
             by= tes: 102400
         }
         traceoptions {
            &nb= sp;          flag all {
                      &nb= sp;            =   disable: false
               = }
         }
     }
}

protocols {
    fib2mrib {
        disable: false
    }
}

------=_Part_841_31610218.1133982752890-- From tdurack@gmail.com Wed Dec 7 21:48:53 2005 From: tdurack@gmail.com (Tim Durack) Date: Wed, 7 Dec 2005 16:48:53 -0500 Subject: [Xorp-users] Re: [Xorp-hackers] OSPF Failures In-Reply-To: <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com> References: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com> <200512051900.jB5J0g0T069778@wyvern.icir.org> <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com> Message-ID: <9e246b4d0512071348y2c848a87u42c045a1f9075d7f@mail.gmail.com> ------=_Part_15257_13731909.1133992133864 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Looks like OSPF crashes right after router receives following LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x8000000= 1 LS checksum 0xdc45 length 32 Link State Acknowledgement Packet: Version 2 Type 5 Router ID 10.1.0.2 Area ID 0.0.0.0 Auth Type 0 LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS checksum 0xdc45 length 32 [ 2005/12/07 13:26:52 FATAL xorp_ospfv2:4320 OSPF +465 routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed Maybe related to some of the other outstanding OSPF bugs. Tim:> On 12/5/05, Tim Durack wrote: > > On 12/5/05, Mike Horn wrote: > > > > Hi Tim, > > > > Take a look at XORP bug 383, your issue looks similar but is for > > different LSA type, however I think it may have the same root cause. B= efore > > the crash did you lose your neighbor adjacency and then reestablish it?= Atanu, > > should a new bug be entered or do you think 383 covers this issue as we= ll? > > > > The adjacency had just been brought up, after starting xorp_rtrmgr and > loading the config. > It seems to happen randomly to all four of the routers in my lab setup. > > Also Tim, there are a number of known issues with the current OSPF code, > > it might be worth quickly perusing the bug database to see what you mig= ht > > run into in a test environment. > > > > I know XORP is still very much beta, but it shows a lot of promise. > I'm using it in a Xen laptop based router lab, to teach and test various > routing protocols and configurations. > > -mike > > > > ------------------------------ > > *From:* xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org= ] > > *On Behalf Of *Tim Durack > > *Sent:* Monday, December 05, 2005 11:26 AM > > *To:* xorp-users@xorp.org; xorp-hackers@xorp.org > > *Subject:* [Xorp-hackers] OSPF Failures > > > > I have created a basic network of four XORP routers, meshed together > > (gre tunnels built outside of XORP.) > > All the adjacencies come up, but OSPF is randomly dying with the > > following error: > > > > [ 2005/12/05 13:08:23 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.c= c > > add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed > > [ 2005/12/05 13:08:23 INFO xorp_rtrmgr:4322 RTRMGR +668 > > module_manager.cc killed ] Module abnormally killed: ospf4 > > [ 2005/12/05 13:08:23 WARNING xorp_rtrmgr:4322 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 faile= d > > Target "ospfv2" does not exist or is not enabled. > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > > protocol ospfv2 shutting down ------- > > OriginTable: ospf > > IGP > > next table =3D Redist:ospf > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > > protocol ospfv2 shutting down ------- > > OriginTable: ospf > > IGP > > next table =3D Redist:ospf > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > > protocol ospfv2 shutting down ------- > > OriginTable: ospf > > IGP > > next table =3D Redist:ospf > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for > > protocol ospfv2 shutting down ------- > > OriginTable: ospf > > IGP > > next table =3D Redist:ospf > > > > > > Not sure why this is happening. I have attached the configs in case it > > helps. > > > > Tim:> > > > > > ------=_Part_15257_13731909.1133992133864 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Looks like OSPF crashes right after router receives following LSA:

LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.0.13 Advertising Router= 10.0.0.1 LS sequence number 0x80000001 LS checksum 0xdc45 length 32
Link State Acknowledgement Packet:
        Version 2
        Type 5
        Router ID 10.1.0.2
        Area ID 0.0.0.0
        Auth Type 0

        LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence num= ber 0x80000001 LS checksum 0xdc45 length 32
[ 2005/12/07 13:26:52  FATAL xorp_ospfv2:4320 OSPF +465 routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed

Maybe related to some of the other outstanding OSPF bugs.

Tim:>

On 12/5/05, Tim Durack <tdurack@gmail.c= om> wrote:
On 12/5/05, Mike Horn &= lt;caddisconsulting@yahoo.co= m> wrote:
Hi Tim,
 
Take a look at XORP bug 383, your issue looks similar but=20 is for different LSA type, however I think it may have the same root=20 cause.  Before the crash did you lose your neighbor adjacency and then= =20 reestablish it?  Atanu, should a new bug be entered or do you=20 think 383 covers this issue as well?

The adjacency had just been brought up, after starting xorp_rtrmgr and load= ing the config.
It seems to happen randomly to all four of the routers in my lab setup.

Also Tim, there are a number of known issues with the=20 current OSPF code, it might be worth quickly perusing the bug database to s= ee=20 what you might run into in a test environment.

I know XORP is still very much beta, but it shows a lot of promise.
I'm using it in a Xen laptop based router lab, to teach and test various ro= uting protocols and configurations.

-mike


From: xorp-hackers-admin@icir.org=20 [mailto:xorp-hackers-admin@i= cir.org] On Behalf Of Tim=20 Durack
Sent: Monday, December 05, 2005 11:26 AM
To:=20 xorp-users@xorp.org; xorp-hackers@xorp.org
Subject: [Xorp-hackers]=20 OSPF Failures

I have created a basic network of four XORP ro= uters, meshed together=20 (gre tunnels built outside of XORP.)
All the adjacencies come up, but OS= PF is=20 randomly dying with the following error:

[ 2005/12/05 13:08:23 = =20 FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 = =3D=3D=20 _entries.count(area)) failed
[ 2005/12/05 13:08:23  INFO=20 xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally= =20 killed: ospf4
[ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322=20 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv= e_xrl=20 ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Comman= d=20 failed Target "ospfv2" does not exist or is not enabled.
[ 200= 5/12/05=20 13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutt= ing=20 down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[= =20 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol o= spfv2=20 shutting down -------
OriginTable: ospf
IGP
next table =3D=20 Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death eve= nt=20 for protocol ospfv2 shutting down -------
OriginTable: ospf
IGP
ne= xt=20 table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received= death=20 event for protocol ospfv2 shutting down -------
OriginTable:=20 ospf
IGP
next table =3D Redist:ospf


Not sure why this is= =20 happening. I have attached the configs in case it=20 helps.

Tim:>



------=_Part_15257_13731909.1133992133864-- From pavlin@icir.org Thu Dec 8 19:27:56 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 11:27:56 -0800 Subject: [Xorp-users] Need help for compiling xorp from current cvs on Linux (IPv6 Multicast) In-Reply-To: Message from abazh of "Mon, 05 Dec 2005 15:44:26 +0700." <438279e60512050044p1e1f3b5bmcf2bd1e9543dd0dc@mail.gmail.com> Message-ID: <200512081927.jB8JRuJ0022500@possum.icir.org> > As I follow previous discussion on IPv6 Multicast routing on Iinux, I have > tried to patch the linux kernel. > I use fedore core 4 with USAGI linux kernel 2.6.14. What is the compiler version (g++ --version)? Anyway, I think I found the problem and committed it to CVS (libproto/proto_node.hh rev 1.33). Pavlin > > My problem is when trying to compile xorp it self, I got below errors: > Making all in . > gmake[3]: Entering directory `/root/xorp/cli' > source=3D'cli_client.cc' object=3D'cli_client.lo' libtool=3Dyes \ > depfile=3D'.deps/cli_client.Plo' tmpdepfile=3D'.deps/cli_client.TPlo' \ > depmode=3Dgcc3 /bin/sh ../config/depcomp \ > /bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-alig= > n > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo `test -f > cli_client.cc || echo './'`cli_client.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -MP -MF > .deps/cli_client.TPlo -o cli_client.o > ../libproto/proto_node.hh: In member function 'uint32_t > ProtoNode::vif_name2vif_index(const std::string&) const': > ../libproto/proto_node.hh:727: error: no matching function for call to > 'find(std::_Rb_tree_const_iterator std::char_traits, std::allocator >, unsigned int> >&)' > gmake[3]: *** [cli_client.lo] Error 1 > gmake[3]: Leaving directory `/root/xorp/cli' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/root/xorp/cli' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/root/xorp' > gmake: *** [all] Error 2 From feamster@lcs.mit.edu Thu Dec 8 20:14:10 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Thu, 8 Dec 2005 15:14:10 -0500 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: <20051206223404.GK30316@lcs.mit.edu> References: <20051206223404.GK30316@lcs.mit.edu> Message-ID: <20051208201408.GA9287@lcs.mit.edu> Hello, I still get this error from time-to-time. What does it mean? [ 2005/12/08 15:13:03 ERROR xorp_rtrmgr:9368 XRL +634 xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? Thanks, Nick On Tue, Dec 06, 2005 at 05:34:06PM -0500, Nick Feamster wrote: > Hi again, > > Can you advise why XORP may be crashing on the following error message? > > [ 2005/12/06 17:29:46 ERROR xorp_rtrmgr:27933 XRL +634 xrl_router.cc > wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? > > Thanks! > Nick From pavlin@icir.org Thu Dec 8 20:24:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 12:24:18 -0800 Subject: [Xorp-users] retaining static routes In-Reply-To: Message from Atanu Ghosh of "Mon, 05 Dec 2005 21:56:29 PST." <73462.1133848589@tigger.icir.org> Message-ID: <200512082024.jB8KOIDx023074@possum.icir.org> > XORP attempts to mark routes that is adds to the kernel, on FreeBSD it > marks them with RTF_PROTO1. When XORP shuts down it should only removed > the marked routes. If XORP is removing routes that were already present > and unmarked this is a bug. > > I just tried a simple experiment on FreeBSD 6.0, I added a static route, > started XORP, then killed it, the route was still there. > > XORP routing protocols will on shutdown attempt to remove all the routes > that they have installed. If for example XORP is configured with a > static route that already existed before XORP was started the route will > be removed. The only way around this would be to take a snapshot of the > routing table on startup and put it back on shutdown. A flag already > exists for interfaces were the original config can be put back on > shutdown. We should perhaps consider a similar option for the routing > table. > > Atanu. I just added a bugzilla entry regarding this configuration flag: http://www.xorp.org/bugzilla/show_bug.cgi?id=413 Tom, please let us know if such flag would be sufficient for your need or whether you had something else in mind. Pavlin > >>>>> "Tom" == Tom Pusateri writes: > > Tom> Is there a way to retain static routes when xorp terminates? > Tom> if they were in before xorp started, it would be nice if it > Tom> would leave them in. Or have a flag to not remove them. > > Tom> Thanks, Tom > > Tom> _______________________________________________ Xorp-users > Tom> mailing list Xorp-users@xorp.org > Tom> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Thu Dec 8 20:29:36 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 12:29:36 -0800 Subject: [Xorp-users] can not find RP in PIM-SM In-Reply-To: Message from Mingquan Wu of "Wed, 07 Dec 2005 14:12:32 EST." <52b73ec80512071112r565098d4j9483927ee6065ce9@mail.gmail.com> Message-ID: <200512082029.jB8KTaPt023129@possum.icir.org> > I tried to configure a linux box as a multicast router using xorp, and als= > o > use it as BST server and RP. Then I have a source (on the same machine) sen= > d > multicast packets to a multicast address, say 224.1.2.3, the router add > the source as a group member but warns that the group 224.1.2.3 does not > have a RP. the following is my configure file, thanks in advance. On startup you have to wait up to approx 2-3 minutes or so until the BSR election is completed and the Cand-RP set is composed. The "show pim bootstrap" xorpsh command will show you the remaining time until the election is completed, and "show pim rps" will show the current Cand-RP set. Pavlin > > interfaces { > interface eth0 { > disable: false > default-system-config > } > interface eth1 { > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > cand-bsr-by-vif-name: "eth0" > /* cand-bsr-by-vif-addr: "192.168.71.49" */ > /* bsr-priority: 1 */ > } > } > > cand-rp { > group-prefix 224.0.0.0/4 { > cand-rp-by-vif-name: "eth0" > /* cand-rp-by-vif-addr: 192.168.71.49 */ > /* rp-priority: 1 */ > /* rp-holdtime: 150 */ > } > } > } > switch-to-spt-threshold { > disable: false > interval-sec: 100 > bytes: 102400 > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > fib2mrib { > disable: false > } > } From pusateri@bangj.com Thu Dec 8 20:34:23 2005 From: pusateri@bangj.com (Tom Pusateri) Date: Thu, 08 Dec 2005 15:34:23 -0500 Subject: [Xorp-users] retaining static routes In-Reply-To: Message from Pavlin Radoslavov of "Thu, 08 Dec 2005 12:24:18 PST." <200512082024.jB8KOIDx023074@possum.icir.org> Message-ID: <20051208203423.F367BB830@jj.bangj.com> In message <200512082024.jB8KOIDx023074@possum.icir.org> you write: >> XORP attempts to mark routes that is adds to the kernel, on FreeBSD it >> marks them with RTF_PROTO1. When XORP shuts down it should only removed >> the marked routes. If XORP is removing routes that were already present >> and unmarked this is a bug. >> >> I just tried a simple experiment on FreeBSD 6.0, I added a static route, >> started XORP, then killed it, the route was still there. >> >> XORP routing protocols will on shutdown attempt to remove all the routes >> that they have installed. If for example XORP is configured with a >> static route that already existed before XORP was started the route will >> be removed. The only way around this would be to take a snapshot of the >> routing table on startup and put it back on shutdown. A flag already >> exists for interfaces were the original config can be put back on >> shutdown. We should perhaps consider a similar option for the routing >> table. >> >> Atanu. > >I just added a bugzilla entry regarding this configuration flag: >http://www.xorp.org/bugzilla/show_bug.cgi?id=413 > >Tom, please let us know if such flag would be sufficient for your >need or whether you had something else in mind. > >Pavlin Pavlin, This is probably more work than you need to do and it doesn't solve the problem of your default being deleted when xorp exits if xorp installed it for you. Can you just add a flag to any route that says not to delete it when xorp exits no matter what the state was before xorp started? Thanks, Tom > >> >>>>> "Tom" == Tom Pusateri writes: >> >> Tom> Is there a way to retain static routes when xorp terminates? >> Tom> if they were in before xorp started, it would be nice if it >> Tom> would leave them in. Or have a flag to not remove them. >> >> Tom> Thanks, Tom >> >> Tom> _______________________________________________ Xorp-users >> Tom> mailing list Xorp-users@xorp.org >> Tom> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users@xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin@icir.org Thu Dec 8 20:39:56 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 12:39:56 -0800 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: Message from Nick Feamster of "Thu, 08 Dec 2005 15:14:10 EST." <20051208201408.GA9287@lcs.mit.edu> Message-ID: <200512082039.jB8KduDh035103@possum.icir.org> > I still get this error from time-to-time. What does it mean? > > [ 2005/12/08 15:13:03 ERROR xorp_rtrmgr:9368 XRL +634 xrl_router.cc > wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? I presume it happens only on startup. Are there any XORP leftover processes when you see the message? Also, can you double-check that the loopback interface is configured properly and is UP. Any additional info can also be useful (e.g., is the error gone if you restart immediately the rtrmgr, etc). Pavlin > On Tue, Dec 06, 2005 at 05:34:06PM -0500, Nick Feamster wrote: > > Hi again, > > > > Can you advise why XORP may be crashing on the following error message? > > > > [ 2005/12/06 17:29:46 ERROR xorp_rtrmgr:27933 XRL +634 xrl_router.cc > > wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? > > > > Thanks! > > Nick > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From feamster@lcs.mit.edu Thu Dec 8 20:43:36 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Thu, 8 Dec 2005 15:43:36 -0500 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: <200512082039.jB8KduDh035103@possum.icir.org> References: <20051208201408.GA9287@lcs.mit.edu> <200512082039.jB8KduDh035103@possum.icir.org> Message-ID: <20051208204336.GC9287@lcs.mit.edu> On Thu, Dec 08, 2005 at 12:39:56PM -0800, Pavlin Radoslavov wrote: > > I still get this error from time-to-time. What does it mean? > > > > [ 2005/12/08 15:13:03 ERROR xorp_rtrmgr:9368 XRL +634 xrl_router.cc > > wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? > > I presume it happens only on startup. Yes, only on startup. > Are there any XORP leftover processes when you see the message? No. > Also, can you double-check that the loopback interface is configured > properly and is UP. [mit_rcp@planetlab1 mit_rcp]$ /sbin/ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:283527002 errors:0 dropped:0 overruns:0 frame:0 TX packets:283527002 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:513931460 (490.1 Mb) TX bytes:513931460 (490.1 Mb) > Any additional info can also be useful (e.g., is the error gone if > you restart immediately the rtrmgr, etc). No, it persists. I am unable to start XORP at all on this machine. -Nick From feamster@lcs.mit.edu Thu Dec 8 20:48:45 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Thu, 8 Dec 2005 15:48:45 -0500 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: <20051208204336.GC9287@lcs.mit.edu> References: <20051208201408.GA9287@lcs.mit.edu> <200512082039.jB8KduDh035103@possum.icir.org> <20051208204336.GC9287@lcs.mit.edu> Message-ID: <20051208204845.GD9287@lcs.mit.edu> One other thing I should probably mention: Occasionally XORP crashes silently, but other times I get the following error: "Timer Expiry *much* later than scheduled: behind by 63.629156 seconds" thanks, -Nick On Thu, Dec 08, 2005 at 03:43:36PM -0500, Nick Feamster wrote: > On Thu, Dec 08, 2005 at 12:39:56PM -0800, Pavlin Radoslavov wrote: > > > I still get this error from time-to-time. What does it mean? > > > > > > [ 2005/12/08 15:13:03 ERROR xorp_rtrmgr:9368 XRL +634 xrl_router.cc > > > wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? > > > > I presume it happens only on startup. > > Yes, only on startup. > > > Are there any XORP leftover processes when you see the message? > > No. > > > Also, can you double-check that the loopback interface is configured > > properly and is UP. > > [mit_rcp@planetlab1 mit_rcp]$ /sbin/ifconfig lo > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:283527002 errors:0 dropped:0 overruns:0 frame:0 > TX packets:283527002 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:513931460 (490.1 Mb) TX bytes:513931460 (490.1 Mb) > > > > Any additional info can also be useful (e.g., is the error gone if > > you restart immediately the rtrmgr, etc). > > No, it persists. I am unable to start XORP at all on this machine. > > -Nick > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Thu Dec 8 20:52:21 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 12:52:21 -0800 Subject: [Xorp-users] retaining static routes In-Reply-To: Message from Tom Pusateri of "Thu, 08 Dec 2005 15:34:23 EST." <20051208203423.F367BB830@jj.bangj.com> Message-ID: <200512082052.jB8KqL2k035269@possum.icir.org> > In message <200512082024.jB8KOIDx023074@possum.icir.org> you write: > >> XORP attempts to mark routes that is adds to the kernel, on FreeBSD it > >> marks them with RTF_PROTO1. When XORP shuts down it should only removed > >> the marked routes. If XORP is removing routes that were already present > >> and unmarked this is a bug. > >> > >> I just tried a simple experiment on FreeBSD 6.0, I added a static route, > >> started XORP, then killed it, the route was still there. > >> > >> XORP routing protocols will on shutdown attempt to remove all the routes > >> that they have installed. If for example XORP is configured with a > >> static route that already existed before XORP was started the route will > >> be removed. The only way around this would be to take a snapshot of the > >> routing table on startup and put it back on shutdown. A flag already > >> exists for interfaces were the original config can be put back on > >> shutdown. We should perhaps consider a similar option for the routing > >> table. > >> > >> Atanu. > > > >I just added a bugzilla entry regarding this configuration flag: > >http://www.xorp.org/bugzilla/show_bug.cgi?id=413 > > > >Tom, please let us know if such flag would be sufficient for your > >need or whether you had something else in mind. > > > >Pavlin > > Pavlin, > This is probably more work than you need to do and it doesn't > solve the problem of your default being deleted when xorp exits if xorp > installed it for you. > > Can you just add a flag to any route that says not to delete it > when xorp exits no matter what the state was before xorp started? I presume you have in mind a flag for only the static routes (i.e., this flag will be per each static route inside the "static" config section)? Pavlin > >> >>>>> "Tom" == Tom Pusateri writes: > >> > >> Tom> Is there a way to retain static routes when xorp terminates? > >> Tom> if they were in before xorp started, it would be nice if it > >> Tom> would leave them in. Or have a flag to not remove them. From pusateri@bangj.com Thu Dec 8 20:56:38 2005 From: pusateri@bangj.com (Tom Pusateri) Date: Thu, 08 Dec 2005 15:56:38 -0500 Subject: [Xorp-users] retaining static routes In-Reply-To: Message from Pavlin Radoslavov of "Thu, 08 Dec 2005 12:52:21 PST." <200512082052.jB8KqL2k035269@possum.icir.org> Message-ID: <20051208205638.F17BDB830@jj.bangj.com> In message <200512082052.jB8KqL2k035269@possum.icir.org> you write: >> In message <200512082024.jB8KOIDx023074@possum.icir.org> you write: >> >> XORP attempts to mark routes that is adds to the kernel, on FreeBSD it >> >> marks them with RTF_PROTO1. When XORP shuts down it should only removed >> >> the marked routes. If XORP is removing routes that were already present >> >> and unmarked this is a bug. >> >> >> >> I just tried a simple experiment on FreeBSD 6.0, I added a static route, >> >> started XORP, then killed it, the route was still there. >> >> >> >> XORP routing protocols will on shutdown attempt to remove all the routes >> >> that they have installed. If for example XORP is configured with a >> >> static route that already existed before XORP was started the route will >> >> be removed. The only way around this would be to take a snapshot of the >> >> routing table on startup and put it back on shutdown. A flag already >> >> exists for interfaces were the original config can be put back on >> >> shutdown. We should perhaps consider a similar option for the routing >> >> table. >> >> >> >> Atanu. >> > >> >I just added a bugzilla entry regarding this configuration flag: >> >http://www.xorp.org/bugzilla/show_bug.cgi?id=413 >> > >> >Tom, please let us know if such flag would be sufficient for your >> >need or whether you had something else in mind. >> > >> >Pavlin >> >> Pavlin, >> This is probably more work than you need to do and it doesn't >> solve the problem of your default being deleted when xorp exits if xorp >> installed it for you. >> >> Can you just add a flag to any route that says not to delete it >> when xorp exits no matter what the state was before xorp started? > >I presume you have in mind a flag for only the static routes (i.e., >this flag will be per each static route inside the "static" config >section)? > >Pavlin That would be sufficient for me at this time but I can envision someone wanting to do an upgrade without stopping forwarding in which case they may want to set this flag even on dynamic routes so I wouldn't limit it to statics. Thanks, Tom > >> >> >>>>> "Tom" == Tom Pusateri writes: >> >> >> >> Tom> Is there a way to retain static routes when xorp terminates? >> >> Tom> if they were in before xorp started, it would be nice if it >> >> Tom> would leave them in. Or have a flag to not remove them. From pavlin@icir.org Thu Dec 8 21:51:59 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 13:51:59 -0800 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: Message from Nick Feamster of "Thu, 08 Dec 2005 15:43:36 EST." <20051208204336.GC9287@lcs.mit.edu> Message-ID: <200512082151.jB8LpxJR035833@possum.icir.org> > > > I still get this error from time-to-time. What does it mean? > > > > > > [ 2005/12/08 15:13:03 ERROR xorp_rtrmgr:9368 XRL +634 xrl_router.cc > > > wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? > > > > I presume it happens only on startup. > > Yes, only on startup. > > > Are there any XORP leftover processes when you see the message? > > No. > > > Also, can you double-check that the loopback interface is configured > > properly and is UP. > > [mit_rcp@planetlab1 mit_rcp]$ /sbin/ifconfig lo > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:283527002 errors:0 dropped:0 overruns:0 frame:0 > TX packets:283527002 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:513931460 (490.1 Mb) TX bytes:513931460 (490.1 Mb) > > > > Any additional info can also be useful (e.g., is the error gone if > > you restart immediately the rtrmgr, etc). > > No, it persists. I am unable to start XORP at all on this machine. Other things to check whether the default XRL TCP port (19999) is not used by some other process. Also, make sure there are no firewall rules that stop the internal XRL TCP communication. If the above is OK, then you can try the following: 1. Verify that you can start by hand "libxipc/xorp_finder -v". 2. Execute "env FINDERTRACE=t libxipc/xorp_finder" in one window, and after that execute "fea/xorp_fea" in another. After you execute "fea/xorp_fea" you should see lots of messages like: [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] register_finder_client(target = "fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1", class = "fea", singleton = "0", cookie = "") -> "687b71f659b1088a" okay [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] register_finder_client(target = "socket_server-a2b810e77fc56205486f00623a0155be@127.0.0.1", class = "socket_server", singleton = "0", cookie = "") -> "687b71f72d46518e" okay [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] add_xrl("finder://fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1/common/0.1/get_status", "stcp", "127.0.0.1:1488") -> okay [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] add_xrl("finder://socket_server-a2b810e77fc56205486f00623a0155be@127.0.0.1/common/0.1/get_status", "stcp", "127.0.0.1:2697") -> okay [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] add_xrl("finder://fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1/common/0.1/get_target_name", "stcp", "127.0.0.1:1488") -> okay If nothing of the above gives you any clue about the issue, then try to create a temporary account on that machine I can use to track down the problem. Pavlin From pavlin@icir.org Thu Dec 8 21:55:14 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 13:55:14 -0800 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: Message from Nick Feamster of "Thu, 08 Dec 2005 15:48:45 EST." <20051208204845.GD9287@lcs.mit.edu> Message-ID: <200512082155.jB8LtEAh035882@possum.icir.org> > One other thing I should probably mention: Occasionally XORP crashes > silently, but other times I get the following error: > > "Timer Expiry *much* later than scheduled: behind by 63.629156 seconds" I presume the CPU load on that machine is reasonably low. Do you have NTP running and how accurate is the internal clock itself? When XORP crashes can you get a coredump and backtrace it? Pavlin From feamster@lcs.mit.edu Thu Dec 8 23:26:00 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Thu, 8 Dec 2005 18:26:00 -0500 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: <200512082151.jB8LpxJR035833@possum.icir.org> References: <20051208204336.GC9287@lcs.mit.edu> <200512082151.jB8LpxJR035833@possum.icir.org> Message-ID: <20051208232600.GL9287@lcs.mit.edu> On Thu, Dec 08, 2005 at 01:51:59PM -0800, Pavlin Radoslavov wrote: > 1. Verify that you can start by hand "libxipc/xorp_finder -v". This seems OK. > 2. Execute "env FINDERTRACE=t libxipc/xorp_finder" in one window, > and after that execute "fea/xorp_fea" in another. After you > execute "fea/xorp_fea" you should see lots of messages like: I'm able to start up both processes, but I don't see any of the traces...silence in both windows. thanks, -Nick > > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > register_finder_client(target = > "fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1", class = "fea", > singleton = "0", cookie = "") -> "687b71f659b1088a" okay > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > register_finder_client(target = > "socket_server-a2b810e77fc56205486f00623a0155be@127.0.0.1", class = > "socket_server", singleton = "0", cookie = "") -> "687b71f72d46518e" > okay > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > add_xrl("finder://fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1/common/0.1/get_status", > "stcp", "127.0.0.1:1488") -> okay > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > add_xrl("finder://socket_server-a2b810e77fc56205486f00623a0155be@127.0.0.1/common/0.1/get_status", > "stcp", "127.0.0.1:2697") -> okay > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > add_xrl("finder://fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1/common/0.1/get_target_name", > "stcp", "127.0.0.1:1488") -> okay > > > > If nothing of the above gives you any clue about the issue, then try > to create a temporary account on that machine I can use to track > down the problem. > > Pavlin From pavlin@icir.org Fri Dec 9 00:31:27 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 08 Dec 2005 16:31:27 -0800 Subject: [Xorp-users] Re: "No Finder" error message? In-Reply-To: Message from Nick Feamster of "Thu, 08 Dec 2005 18:26:00 EST." <20051208232600.GL9287@lcs.mit.edu> Message-ID: <200512090031.jB90VRxx036896@possum.icir.org> > On Thu, Dec 08, 2005 at 01:51:59PM -0800, Pavlin Radoslavov wrote: > > 1. Verify that you can start by hand "libxipc/xorp_finder -v". > > This seems OK. > > > 2. Execute "env FINDERTRACE=t libxipc/xorp_finder" in one window, > > and after that execute "fea/xorp_fea" in another. After you > > execute "fea/xorp_fea" you should see lots of messages like: > > I'm able to start up both processes, but I don't see any of the > traces...silence in both windows. Probably there is something that affects the TCP communication between both processes. If there are no firewall rules that may affect TCP, then the temp. account can be very helpful to proceed further with the chasing of the problem. Pavlin > > > > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > > register_finder_client(target = > > "fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1", class = "fea", > > singleton = "0", cookie = "") -> "687b71f659b1088a" okay > > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > > register_finder_client(target = > > "socket_server-a2b810e77fc56205486f00623a0155be@127.0.0.1", class = > > "socket_server", singleton = "0", cookie = "") -> "687b71f72d46518e" > > okay > > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > > add_xrl("finder://fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1/common/0.1/get_status", > > "stcp", "127.0.0.1:1488") -> okay > > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > > add_xrl("finder://socket_server-a2b810e77fc56205486f00623a0155be@127.0.0.1/common/0.1/get_status", > > "stcp", "127.0.0.1:2697") -> okay > > [ 2005/12/08 13:48:39 INFO xorp_finder XifFinderClient ] > > add_xrl("finder://fea-b0c076d86dbb1cdf1648730a89c6629f@127.0.0.1/common/0.1/get_target_name", > > "stcp", "127.0.0.1:1488") -> okay > > > > > > > > If nothing of the above gives you any clue about the issue, then try > > to create a temporary account on that machine I can use to track > > down the problem. > > > > Pavlin From abazh18@gmail.com Fri Dec 9 06:16:58 2005 From: abazh18@gmail.com (abazh) Date: Fri, 9 Dec 2005 13:16:58 +0700 Subject: [Xorp-users] Re: Need help for compiling xorp from current cvs on Linux (IPv6 Multicast) In-Reply-To: <200512081927.jB8JRuJ0022500@possum.icir.org> References: <438279e60512050044p1e1f3b5bmcf2bd1e9543dd0dc@mail.gmail.com> <200512081927.jB8JRuJ0022500@possum.icir.org> Message-ID: <438279e60512082216hb86399dta33a15b960ee77c1@mail.gmail.com> I use gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) After trying to compile again, I got not as in previous, but got another following errors: source='ifconfig_get_getifaddrs.cc' object='ifconfig_get_getifaddrs.lo' libtool=yes \ depfile='.deps/ifconfig_get_getifaddrs.Plo' tmpdepfile='.deps/ifconfig_get_getifaddrs.TPlo' \ depmode=gcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o ifconfig_get_getifaddrs.lo `test -f ifconfig_get_getifaddrs.cc || echo './'`ifconfig_get_getifaddrs.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -c ifconfig_get_getifaddrs.cc -MT ifconfig_get_getifaddrs.lo -MD -MP -MF .deps/ifconfig_get_getifaddrs.TPlo -o ifconfig_get_getifaddrs.o cc1plus: warnings being treated as errors ifconfig_get_getifaddrs.cc: In member function 'bool IfConfigGetGetifaddrs::read_config(IfTree&)': ifconfig_get_getifaddrs.cc:108: warning: cast from type 'ifaddrs**' to type 'const ifaddrs**' casts away constness make[3]: *** [ifconfig_get_getifaddrs.lo] Error 1 make[3]: Leaving directory `/usr/local/xorp/src/xorp/fea' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/xorp/src/xorp/fea' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/xorp/src/xorp' make: *** [all] Error 2 On 12/9/05, Pavlin Radoslavov wrote: > > As I follow previous discussion on IPv6 Multicast routing on Iinux, I have > > tried to patch the linux kernel. > > I use fedore core 4 with USAGI linux kernel 2.6.14. > > What is the compiler version (g++ --version)? > > Anyway, I think I found the problem and committed it to CVS > (libproto/proto_node.hh rev 1.33). > > Pavlin > > > > > > My problem is when trying to compile xorp it self, I got below errors: > > Making all in . > > gmake[3]: Entering directory `/root/xorp/cli' > > source=3D'cli_client.cc' object=3D'cli_client.lo' libtool=3Dyes \ > > depfile=3D'.deps/cli_client.Plo' tmpdepfile=3D'.deps/cli_client.TPlo' \ > > depmode=3Dgcc3 /bin/sh ../config/depcomp \ > > /bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. > > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith > -Wcast-alig= > > n > > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo `test > -f > > cli_client.cc || echo './'`cli_client.cc > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > > -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -MP -MF > > .deps/cli_client.TPlo -o cli_client.o > > ../libproto/proto_node.hh: In member function 'uint32_t > > ProtoNode::vif_name2vif_index(const std::string&) const': > > ../libproto/proto_node.hh:727: error: no matching function for call to > > 'find(std::_Rb_tree_const_iterator > std::char_traits, std::allocator >, unsigned int> >&)' > > gmake[3]: *** [cli_client.lo] Error 1 > > gmake[3]: Leaving directory `/root/xorp/cli' > > gmake[2]: *** [all-recursive] Error 1 > > gmake[2]: Leaving directory `/root/xorp/cli' > > gmake[1]: *** [all-recursive] Error 1 > > gmake[1]: Leaving directory `/root/xorp' > > gmake: *** [all] Error 2 > From c-otto@gmx.de Fri Dec 9 20:23:57 2005 From: c-otto@gmx.de (Carsten Otto) Date: Fri, 9 Dec 2005 21:23:57 +0100 Subject: [Xorp-users] RAM-Usage Message-ID: <20051209202357.GA17227@carsten-otto.halifax.rwth-aachen.de> --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi there! XORP is running fine (at least here :P), but I noticed a quite high memory usage: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28960 root 15 0 653m 345m 1780 S 1.7 68.6 427:26.51 xorp_pimsm4 The PC in question has 512 MB RAM and does Gigabit-Routing of Unicast and Multicast (High Traffic, many groups). Is this memory footage normal? Thanks, --=20 Carsten Otto c-otto@gmx.de www.c-otto.de --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmefdjUF4jpCSQBQRAvqZAJ9fIXe8YLyeAjcNLuxwBzEPaoGbqwCg7xCx ozGENKMJ/7ndRseoMvskclY= =K8ab -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From pavlin@icir.org Fri Dec 9 20:36:39 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 09 Dec 2005 12:36:39 -0800 Subject: [Xorp-users] RAM-Usage In-Reply-To: Message from Carsten Otto of "Fri, 09 Dec 2005 21:23:57 +0100." <20051209202357.GA17227@carsten-otto.halifax.rwth-aachen.de> Message-ID: <200512092036.jB9KadWv059656@possum.icir.org> > XORP is running fine (at least here :P), but I noticed a quite high > memory usage: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 28960 root 15 0 653m 345m 1780 S 1.7 68.6 427:26.51 xorp_pimsm4 > > The PC in question has 512 MB RAM and does Gigabit-Routing of Unicast > and Multicast (High Traffic, many groups). Is this memory footage > normal? The memory usage seems a little bit too high. BTW, is it growing over time or is it a relatively constant. Also, how many groups and senders are there, and what is the size of the unicast routing table. Pavlin From c-otto@gmx.de Fri Dec 9 20:45:05 2005 From: c-otto@gmx.de (Carsten Otto) Date: Fri, 9 Dec 2005 21:45:05 +0100 Subject: [Xorp-users] RAM-Usage In-Reply-To: <200512092036.jB9KadWv059656@possum.icir.org> References: <20051209202357.GA17227@carsten-otto.halifax.rwth-aachen.de> <200512092036.jB9KadWv059656@possum.icir.org> Message-ID: <20051209204505.GA30200@carsten-otto.halifax.rwth-aachen.de> --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 09, 2005 at 12:36:39PM -0800, Pavlin Radoslavov wrote: > The memory usage seems a little bit too high. BTW, is it growing > over time or is it a relatively constant. Ask me again tomorrow :) It was at about 5 MB at the start I think. > Also, how many groups and senders are there, and what is the size of > the unicast routing table. First of all I am connected to the MBone, so there are quite a few senders. In the internal network I have at the moment three senders (and some MACs with their multicast low-bandwith thingy) putting out about 300 MBit/sec together. About 200 addresses/groups are used for that. Only about 50 MBit/sec (maximum) are streamed out atm. The Unicast Routing Table is very small, just one internal and one external network (Unicast Routing is not handled by XORP I think). Thanks, --=20 Carsten Otto c-otto@gmx.de www.c-otto.de --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmezRjUF4jpCSQBQRAhO5AKDXzITMprXgsS3Dxy9CpnQVkv/p/QCgktEt p6UG70pYh28o161/23ItoDo= =mM1d -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From pavlin@icir.org Fri Dec 9 20:52:17 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 09 Dec 2005 12:52:17 -0800 Subject: [Xorp-users] RAM-Usage In-Reply-To: Message from Carsten Otto of "Fri, 09 Dec 2005 21:45:05 +0100." <20051209204505.GA30200@carsten-otto.halifax.rwth-aachen.de> Message-ID: <200512092052.jB9KqH6i059815@possum.icir.org> > > Also, how many groups and senders are there, and what is the size of > > the unicast routing table. > > First of all I am connected to the MBone, so there are quite a few > senders. In the internal network I have at the moment three senders (and > some MACs with their multicast low-bandwith thingy) putting out about > 300 MBit/sec together. About 200 addresses/groups are used for that. > Only about 50 MBit/sec (maximum) are streamed out atm. Are those senders directly connected to XORP and is XORP the DR for the LAN with the senders. If the senders are transmitting with relatively high bw, I am trying to find out whether this translates into PIM Registers overhead in user space (inside xorp_pimsm4). > The Unicast Routing Table is very small, just one internal and one > external network (Unicast Routing is not handled by XORP I think). Even if the unicast routing is not handled by XORP, the unicast routing table is converged into MRIB that is inside xorp_pimsm4. Though, please double-check with "netstat -rn" that the kernel forwarding table is indeed very small. Pavlin From c-otto@gmx.de Fri Dec 9 20:58:56 2005 From: c-otto@gmx.de (Carsten Otto) Date: Fri, 9 Dec 2005 21:58:56 +0100 Subject: [Xorp-users] RAM-Usage In-Reply-To: <200512092052.jB9KqH6i059815@possum.icir.org> References: <20051209204505.GA30200@carsten-otto.halifax.rwth-aachen.de> <200512092052.jB9KqH6i059815@possum.icir.org> Message-ID: <20051209205856.GA25620@carsten-otto.halifax.rwth-aachen.de> --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 09, 2005 at 12:52:17PM -0800, Pavlin Radoslavov wrote: > Are those senders directly connected to XORP and is XORP the DR for > the LAN with the senders. If the senders are transmitting with > relatively high bw, I am trying to find out whether this translates > into PIM Registers overhead in user space (inside xorp_pimsm4). Between XORP and the senders is one switch (HP 6108) for the most busy sender and this 6108 and another switch, AT Rapier G6, between XORP and the other senders. Of course XORP is DR :) This causes XORP to request quite a lot of traffic, which is not my problem (but perhaps causes this overhead). > Even if the unicast routing is not handled by XORP, the > unicast routing table is converged into MRIB that is inside > xorp_pimsm4. Though, please double-check with "netstat -rn" that the > kernel forwarding table is indeed very small. It is. --=20 Carsten Otto c-otto@gmx.de www.c-otto.de --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmfAQjUF4jpCSQBQRApNpAJ4oQa9udtCukFpU/UQZvF0TtU/H2QCePeSZ pQwzqqk3UOMoTtgDuIRX+1g= =2TJC -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From c-otto@gmx.de Sat Dec 10 12:50:35 2005 From: c-otto@gmx.de (Carsten Otto) Date: Sat, 10 Dec 2005 13:50:35 +0100 Subject: [Xorp-users] RAM-Usage In-Reply-To: <200512092036.jB9KadWv059656@possum.icir.org> References: <20051209202357.GA17227@carsten-otto.halifax.rwth-aachen.de> <200512092036.jB9KadWv059656@possum.icir.org> Message-ID: <20051210125035.GA10824@carsten-otto.halifax.rwth-aachen.de> --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 09, 2005 at 12:36:39PM -0800, Pavlin Radoslavov wrote: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 28960 root 15 0 653m 345m 1780 S 1.7 68.6 427:26.51 xorp_pimsm4 > The memory usage seems a little bit too high. BTW, is it growing > over time or is it a relatively constant. today: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND = =20 28960 root 15 0 653m 345m 1780 S 1.7 68.7 432:51.23 xorp_pimsm4 = =20 --=20 Carsten Otto c-otto@gmx.de www.c-otto.de --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDms8bjUF4jpCSQBQRAs7yAKDHnCbSqKbfTbvEhV+A/fgmFBK5cwCg9r7u Y2cPeyCr3ub5CxG9ldRgZaE= =g0uq -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From pavlin@icir.org Tue Dec 13 22:54:56 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 13 Dec 2005 14:54:56 -0800 Subject: [Xorp-users] Re: Need help for compiling xorp from current cvs on Linux (IPv6 Multicast) In-Reply-To: Message from abazh of "Fri, 09 Dec 2005 13:16:58 +0700." <438279e60512082216hb86399dta33a15b960ee77c1@mail.gmail.com> Message-ID: <200512132254.jBDMsuur088892@possum.icir.org> > I use gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) All gcc-4.0.2 compilation problems should now be fixed in CVS. The last commit just went in so make sure that you have a recent checkout tree with the following file revisions: libxorp/callback-gen.py rev 1.15 libxorp/callback_debug.hh rev. 1.10 libxorp/callback_nodebug.hh rev. 1.8 Pavlin P.S. There is already bugzilla entry about those gcc-4.0.2 compilation errors, so please use that entry if there are any other similar issues: http://www.xorp.org/bugzilla/show_bug.cgi?id=414 > > After trying to compile again, I got not as in previous, but got > another following errors: > > source='ifconfig_get_getifaddrs.cc' > object='ifconfig_get_getifaddrs.lo' libtool=yes \ > depfile='.deps/ifconfig_get_getifaddrs.Plo' > tmpdepfile='.deps/ifconfig_get_getifaddrs.TPlo' \ > depmode=gcc3 /bin/sh ../config/depcomp \ > /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. > -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror > -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 > -pipe -c -o ifconfig_get_getifaddrs.lo `test -f > ifconfig_get_getifaddrs.cc || echo './'`ifconfig_get_getifaddrs.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-25 -pipe -c ifconfig_get_getifaddrs.cc -MT > ifconfig_get_getifaddrs.lo -MD -MP -MF > .deps/ifconfig_get_getifaddrs.TPlo -o ifconfig_get_getifaddrs.o > cc1plus: warnings being treated as errors > ifconfig_get_getifaddrs.cc: In member function 'bool > IfConfigGetGetifaddrs::read_config(IfTree&)': > ifconfig_get_getifaddrs.cc:108: warning: cast from type 'ifaddrs**' to > type 'const ifaddrs**' casts away constness > make[3]: *** [ifconfig_get_getifaddrs.lo] Error 1 > make[3]: Leaving directory `/usr/local/xorp/src/xorp/fea' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/xorp/src/xorp/fea' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/xorp/src/xorp' > make: *** [all] Error 2 > > > On 12/9/05, Pavlin Radoslavov wrote: > > > As I follow previous discussion on IPv6 Multicast routing on Iinux, I have > > > tried to patch the linux kernel. > > > I use fedore core 4 with USAGI linux kernel 2.6.14. > > > > What is the compiler version (g++ --version)? > > > > Anyway, I think I found the problem and committed it to CVS > > (libproto/proto_node.hh rev 1.33). > > > > Pavlin > > > > > > > > > > My problem is when trying to compile xorp it self, I got below errors: > > > Making all in . > > > gmake[3]: Entering directory `/root/xorp/cli' > > > source=3D'cli_client.cc' object=3D'cli_client.lo' libtool=3Dyes \ > > > depfile=3D'.deps/cli_client.Plo' tmpdepfile=3D'.deps/cli_client.TPlo' \ > > > depmode=3Dgcc3 /bin/sh ../config/depcomp \ > > > /bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. > > > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith > > -Wcast-alig= > > > n > > > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo `test > > -f > > > cli_client.cc || echo './'`cli_client.cc > > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > > > -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -MP -MF > > > .deps/cli_client.TPlo -o cli_client.o > > > ../libproto/proto_node.hh: In member function 'uint32_t > > > ProtoNode::vif_name2vif_index(const std::string&) const': > > > ../libproto/proto_node.hh:727: error: no matching function for call to > > > 'find(std::_Rb_tree_const_iterator > > std::char_traits, std::allocator >, unsigned int> >&)' > > > gmake[3]: *** [cli_client.lo] Error 1 > > > gmake[3]: Leaving directory `/root/xorp/cli' > > > gmake[2]: *** [all-recursive] Error 1 > > > gmake[2]: Leaving directory `/root/xorp/cli' > > > gmake[1]: *** [all-recursive] Error 1 > > > gmake[1]: Leaving directory `/root/xorp' > > > gmake: *** [all] Error 2 > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Wed Dec 14 02:58:15 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 13 Dec 2005 18:58:15 -0800 Subject: [Xorp-users] RAM-Usage In-Reply-To: Message from Carsten Otto of "Sat, 10 Dec 2005 13:50:35 +0100." <20051210125035.GA10824@carsten-otto.halifax.rwth-aachen.de> Message-ID: <200512140258.jBE2wF79044722@possum.icir.org> > > --cWoXeonUoKmBZSoM > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Dec 09, 2005 at 12:36:39PM -0800, Pavlin Radoslavov wrote: > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > 28960 root 15 0 653m 345m 1780 S 1.7 68.6 427:26.51 xorp_pimsm4 > > The memory usage seems a little bit too high. BTW, is it growing > > over time or is it a relatively constant. > > today: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND = > =20 > 28960 root 15 0 653m 345m 1780 S 1.7 68.7 432:51.23 xorp_pimsm4 = > =20 So it doesn't look like a memory leak. My guess is that there is some transient queueing that is built during startup. This queueing may be triggered by the large bw of the senders (e.g., because of the userland PIM Register encapsulation). For example, on transmission all protocol messages are queued inside xorp_pimsm4, and this includes the PIM Register messages with the encapsulated data packets. Please let me know if you are willing to investigate further this issue and then we can do it offline. Pavlin From c-otto@gmx.de Wed Dec 14 09:59:49 2005 From: c-otto@gmx.de (Carsten Otto) Date: Wed, 14 Dec 2005 10:59:49 +0100 Subject: [Xorp-users] RAM-Usage In-Reply-To: <200512140258.jBE2wF79044722@possum.icir.org> References: <20051210125035.GA10824@carsten-otto.halifax.rwth-aachen.de> <200512140258.jBE2wF79044722@possum.icir.org> Message-ID: <20051214095949.GA16258@carsten-otto.halifax.rwth-aachen.de> --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 13, 2005 at 06:58:15PM -0800, Pavlin Radoslavov wrote: > Please let me know if you are willing to investigate further this > issue and then we can do it offline. Yeah, we can do that. BTW, I restarted XORP yesterday and now I have: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15648 root 15 0 66908 62m 2816 S 2.0 12.4 15:55.68 xorp_pimsm4 Ciao, --=20 Carsten Otto c-otto@gmx.de www.c-otto.de --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDn+0VjUF4jpCSQBQRAih3AKCXD7d8yyrf+oxcL1HiMs675vj6iwCZAWqU 4tMNv+BnRexalWmtAM+u9Po= =UlZz -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From themaxxz@themaxxz.org Thu Dec 15 20:21:07 2005 From: themaxxz@themaxxz.org (themaxxz@themaxxz.org) Date: Thu, 15 Dec 2005 21:21:07 +0100 Subject: [Xorp-users] PIM-SM Message-ID: <20051215202107.GA6365@skynet> Hi, I'm trying to get a small network going as described on http://www.netcraftsmen.net/welcher/papers/multicast03.html The BSR & RP router is configured as below: /*XORP Configuration File, v1.0*/ interfaces { interface eth0 { description: "??" vif eth0 { disable: false address 192.168.4.2 { prefix-length: 24 disable: false broadcast: 192.168.4.255 } } disable: false discard: false } interface eth1 { description: "??" vif eth1 { disable: false address 192.168.6.2 { prefix-length: 24 disable: false broadcast: 192.168.6.255 } } disable: false discard: false } interface lo { description: "Loopback interface" vif lo { disable: false address 1.1.1.1 { prefix-length: 32 disable: false } } disable: false discard: false } targetname: "fea" } protocols { static { route4 0.0.0.0/0 { next-hop: 192.168.4.1 metric: 1 } targetname: "static_routes" disable: false } igmp { targetname: "IGMP" disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } traceoptions { flag { all { disable: true } } } } pimsm4 { targetname: "PIMSM_4" disable: false interface eth0 { vif eth0 { disable: false dr-priority: 1 } } interface eth1 { vif eth1 { disable: false dr-priority: 1 } } interface register_vif { vif register_vif { disable: false dr-priority: 1 } } bootstrap { disable: false cand-rp { group-prefix 224.0.0.0/4 { is-scope-zone: false rp-priority: 192 rp-holdtime: 150 cand-rp-by-vif-name: "lo" } } cand-bsr { scope-zone 224.0.0.0/4 { is-scope-zone: false bsr-priority: 1 hash-mask-len: 30 cand-bsr-by-vif-name: "lo" } } } traceoptions { flag { all { disable: false } } } } fib2mrib { disable: false } } plumbing { mfea4 { targetname: "MFEA_4" disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag { all { disable: true } } } } } fea { unicast-forwarding4 { disable: false } targetname: "fea" } Shortly after startup I see on a neighbor router Xorp> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix 1.1.1.1 bootstrap 192 150 132 0 224.0.0.0/4 Xorp> show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 1.1.1.1 1 0.0.0.0 0 AcceptPreferred 26 1196 But after a while these entries fanish after the Timeout and SZTimeout However I regulary see incoming bootstrap messages from Elected BSR, so the Timeouts should be reset shouldnt they? [ 2005/12/16 08:45:43 TRACE xorp_pimsm4 PIM ] RX PIM_BOOTSTRAP from 192.168.4.2 to 224.0.0.13 on vif eth2 What am I missing? Thanks, TM From abazh18@gmail.com Fri Dec 16 01:37:57 2005 From: abazh18@gmail.com (abazh) Date: Fri, 16 Dec 2005 08:37:57 +0700 Subject: [Xorp-users] Re: Need help for compiling xorp from current cvs on Linux (IPv6 Multicast) In-Reply-To: <200512132254.jBDMsuur088892@possum.icir.org> References: <438279e60512082216hb86399dta33a15b960ee77c1@mail.gmail.com> <200512132254.jBDMsuur088892@possum.icir.org> Message-ID: <438279e60512151737m4a40f162q4b2bd3bbe018fbdf@mail.gmail.com> ------=_Part_145_20957428.1134697077973 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Everything works well on the compilation, thank you. Currently I still doing further test with my existing IPv6 multicast router= . On 12/14/05, Pavlin Radoslavov wrote: > > > I use gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) > > All gcc-4.0.2 compilation problems should now be fixed in CVS. The > last commit just went in so make sure that you have a recent > checkout tree with the following file revisions: > > libxorp/callback-gen.py rev 1.15 > libxorp/callback_debug.hh rev. 1.10 > libxorp/callback_nodebug.hh rev. 1.8 > > Pavlin > > P.S. There is already bugzilla entry about those gcc-4.0.2 > compilation errors, so please use that entry if there are any other > similar issues: > > http://www.xorp.org/bugzilla/show_bug.cgi?id=3D414 > > > > > After trying to compile again, I got not as in previous, but got > > another following errors: > > > > source=3D'ifconfig_get_getifaddrs.cc' > > object=3D'ifconfig_get_getifaddrs.lo' libtool=3Dyes \ > > depfile=3D'.deps/ifconfig_get_getifaddrs.Plo' > > tmpdepfile=3D'.deps/ifconfig_get_getifaddrs.TPlo' \ > > depmode=3Dgcc3 /bin/sh ../config/depcomp \ > > /bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. > > -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror > > -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 > > -pipe -c -o ifconfig_get_getifaddrs.lo `test -f > > ifconfig_get_getifaddrs.cc || echo './'`ifconfig_get_getifaddrs.cc > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > > -ftemplate-depth-25 -pipe -c ifconfig_get_getifaddrs.cc -MT > > ifconfig_get_getifaddrs.lo -MD -MP -MF > > .deps/ifconfig_get_getifaddrs.TPlo -o ifconfig_get_getifaddrs.o > > cc1plus: warnings being treated as errors > > ifconfig_get_getifaddrs.cc: In member function 'bool > > IfConfigGetGetifaddrs::read_config(IfTree&)': > > ifconfig_get_getifaddrs.cc:108: warning: cast from type 'ifaddrs**' to > > type 'const ifaddrs**' casts away constness > > make[3]: *** [ifconfig_get_getifaddrs.lo] Error 1 > > make[3]: Leaving directory `/usr/local/xorp/src/xorp/fea' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/usr/local/xorp/src/xorp/fea' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/usr/local/xorp/src/xorp' > > make: *** [all] Error 2 > > > > > > On 12/9/05, Pavlin Radoslavov wrote: > > > > As I follow previous discussion on IPv6 Multicast routing on Iinux, > I have > > > > tried to patch the linux kernel. > > > > I use fedore core 4 with USAGI linux kernel 2.6.14. > > > > > > What is the compiler version (g++ --version)? > > > > > > Anyway, I think I found the problem and committed it to CVS > > > (libproto/proto_node.hh rev 1.33). > > > > > > Pavlin > > > > > > > > > > > > > > My problem is when trying to compile xorp it self, I got below > errors: > > > > Making all in . > > > > gmake[3]: Entering directory `/root/xorp/cli' > > > > source=3D3D'cli_client.cc' object=3D3D'cli_client.lo' libtool=3D3Dy= es \ > > > > depfile=3D3D'.deps/cli_client.Plo' > tmpdepfile=3D3D'.deps/cli_client.TPlo' \ > > > > depmode=3D3Dgcc3 /bin/sh ../config/depcomp \ > > > > /bin/sh ../libtool --mode=3D3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -= I.. > -I.. > > > > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith > > > -Wcast-alig=3D > > > > n > > > > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo > `test > > > -f > > > > cli_client.cc || echo './'`cli_client.cc > > > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > > > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align > -Woverloaded-virtual > > > > -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -M= P > -MF > > > > .deps/cli_client.TPlo -o cli_client.o > > > > ../libproto/proto_node.hh: In member function 'uint32_t > > > > ProtoNode::vif_name2vif_index(const std::string&) const': > > > > ../libproto/proto_node.hh:727: error: no matching function for call > to > > > > 'find(std::_Rb_tree_const_iterator std::basic_string > > > std::char_traits, std::allocator >, unsigned int> >&)' > > > > gmake[3]: *** [cli_client.lo] Error 1 > > > > gmake[3]: Leaving directory `/root/xorp/cli' > > > > gmake[2]: *** [all-recursive] Error 1 > > > > gmake[2]: Leaving directory `/root/xorp/cli' > > > > gmake[1]: *** [all-recursive] Error 1 > > > > gmake[1]: Leaving directory `/root/xorp' > > > > gmake: *** [all] Error 2 > > > > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users@xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > ------=_Part_145_20957428.1134697077973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Everything works well on the compilation, thank you.
Currently I still doing further test with my existing IPv6 multicast router= .

On 12/14/05, Pavlin Radoslavov <pavlin@ic= ir.org> wrote:
> I use gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)

All gcc-4.0.= 2 compilation problems should now be fixed in CVS. The
last commit just = went in so make sure that you have a recent
checkout tree with the follo= wing file revisions:

libxorp/callback-gen.py rev 1.15
libxorp/callback_debug.hh rev. = 1.10
libxorp/callback_nodebug.hh rev. 1.8

Pavlin

P.S. Ther= e is already bugzilla entry about those gcc-4.0.2
compilation errors, so= please use that entry if there are any other
similar issues:

http://www.xorp.org/bugzilla/show_bug.cgi?id=3D414
>
> After trying to compile again, I got not as in previous, but= got
> another following errors:
>
> source=3D'ifconfig_get_g= etifaddrs.cc'
> object=3D'ifconfig_get_getifaddrs.lo' libtool=3Dyes \=
> depfile=3D'.deps/ifconfig_get_getifaddrs.Plo'
> tmpdepfile= =3D'.deps/ifconfig_get_getifaddrs.TPlo' \
> depmode=3Dgcc3 /bin/sh ../config/depcomp \
> /bin/sh ../libt= ool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I..
> -I.. &nb= sp;  -g -W -Wall -Wwrite-strings -Wcast-qual -Werror
> -Wpo= inter-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25
> -pipe -c -o ifconfig_get_getifaddrs.lo `test -f
> ifconfig_g= et_getifaddrs.cc || echo './'`ifconfig_get_getifaddrs.cc
> g++ -DHAVE= _CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings
> -Wcast-qual= -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual
> -ftemplate-depth-25 -pipe -c ifconfig_get_getifaddrs.cc -MT
>= ; ifconfig_get_getifaddrs.lo -MD -MP -MF
> .deps/ifconfig_get_getifad= drs.TPlo -o ifconfig_get_getifaddrs.o
> cc1plus: warnings being treat= ed as errors
> ifconfig_get_getifaddrs.cc: In member function 'bool
> IfCon= figGetGetifaddrs::read_config(IfTree&)':
> ifconfig_get_getifaddr= s.cc:108: warning: cast from type 'ifaddrs**' to
> type 'const ifaddr= s**' casts away constness
> make[3]: *** [ifconfig_get_getifaddrs.lo] Error 1
> make[3]:= Leaving directory `/usr/local/xorp/src/xorp/fea'
> make[2]: *** [all= -recursive] Error 1
> make[2]: Leaving directory `/usr/local/xorp/src= /xorp/fea'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving dire= ctory `/usr/local/xorp/src/xorp'
> make: *** [all] Error 2
>>
> On 12/9/05, Pavlin Radoslavov < pavlin@icir.org> wrote:
> > > As I follow previous discu= ssion on IPv6 Multicast routing on Iinux, I have
> > > tried to= patch the linux kernel.
> > > I use fedore core 4 with USAGI l= inux kernel=20 2.6.14.
> >
> > What is the compiler version (g++ --versi= on)?
> >
> > Anyway, I think I found the problem and comm= itted it to CVS
> > (libproto/proto_node.hh rev 1.33).
> >= ;
> > Pavlin
> >
> >
> > >
> &g= t; > My problem is when trying to compile xorp it self, I got below erro= rs:
> > > Making all in .
> > > gmake[3]: Entering = directory `/root/xorp/cli'
> > > source=3D3D'cli_client.cc' object=3D3D'cli_client.lo' li= btool=3D3Dyes \
> > > depfile=3D3D'.deps/cli_client.Plo' tmpdep= file=3D3D'.deps/cli_client.TPlo' \
> > > depmode=3D3Dgcc3 /bin/= sh ../config/depcomp \
> > > /bin/sh ../libtool --mode=3D3Dcompile g++ -DHAVE_CONFIG_= H -I. -I. -I.. -I..
> > > -g -W -Wall -Wwrite-strings -Wcast-qu= al -Werror -Wpointer-arith
> > -Wcast-alig=3D
> > > n<= br> > > > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_cli= ent.lo `test
> > -f
> > > cli_client.cc || echo './'`c= li_client.cc
> > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W = -Wall -Wwrite-strings
> > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverl= oaded-virtual
> > > -ftemplate-depth-25 -pipe -c cli_client.cc = -MT cli_client.lo -MD -MP -MF
> > > .deps/cli_client.TPlo -o cl= i_client.o
> > > ../libproto/proto_node.hh: In member function 'uint32_t<= br>> > > ProtoNode<V>::vif_name2vif_index(const std::string&= amp;) const':
> > > ../libproto/proto_node.hh:727: error: no ma= tching function for call to
> > > 'find(std::_Rb_tree_const_iterator<std::pair<const= std::basic_string<char,
> > > std::char_traits<char>,= std::allocator<char> >, unsigned int> >&)'
> >= > gmake[3]: *** [cli_client.lo] Error 1
> > > gmake[3]: Leaving directory `/root/xorp/cli'
> >= ; > gmake[2]: *** [all-recursive] Error 1
> > > gmake[2]: Le= aving directory `/root/xorp/cli'
> > > gmake[1]: *** [all-recur= sive] Error 1
> > > gmake[1]: Leaving directory `/root/xorp'
> > &g= t; gmake: *** [all] Error 2
> >
>
> __________________= _____________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/list= info/xorp-users


------=_Part_145_20957428.1134697077973-- From pavlin@icir.org Fri Dec 16 02:13:01 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 15 Dec 2005 18:13:01 -0800 Subject: [Xorp-users] PIM-SM In-Reply-To: Message from themaxxz@themaxxz.org of "Thu, 15 Dec 2005 21:21:07 +0100." <20051215202107.GA6365@skynet> Message-ID: <200512160213.jBG2D1nW015899@possum.icir.org> In your config you are using the loopback "lo" interface to configure the Cand-RP/Cand-BSR. I'd recommend that you use eth0 or eth1 instead. If "lo" is not enabled inside the pimsm4 configuration, then you shouldn't be able to use it for any other PIM-SM purpose (the fact that it was used temporarily on startup is probably a bug). On the other hand, I wouldn't recommend enabling the loopback interface inside PIM-SM, because then you would have to enable it inside the "igmp" and "mfea4" sections, and the result for that may be unpredictable: it _may_ work, but I have never tested it so it is safer to stick with what is known to work. Pavlin > The BSR & RP router is configured as below: > > /*XORP Configuration File, v1.0*/ > interfaces { > interface eth0 { > description: "??" > vif eth0 { > disable: false > address 192.168.4.2 { > prefix-length: 24 > disable: false > broadcast: 192.168.4.255 > } > } > disable: false > discard: false > } > interface eth1 { > description: "??" > vif eth1 { > disable: false > address 192.168.6.2 { > prefix-length: 24 > disable: false > broadcast: 192.168.6.255 > } > } > disable: false > discard: false > } > interface lo { > description: "Loopback interface" > vif lo { > disable: false > address 1.1.1.1 { > prefix-length: 32 > disable: false > } > } > disable: false > discard: false > } > targetname: "fea" > } > protocols { > static { > route4 0.0.0.0/0 { > next-hop: 192.168.4.1 > metric: 1 > } > targetname: "static_routes" > disable: false > } > igmp { > targetname: "IGMP" > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > traceoptions { > flag { > all { > disable: true > } > } > } > } > pimsm4 { > targetname: "PIMSM_4" > disable: false > interface eth0 { > vif eth0 { > disable: false > dr-priority: 1 > } > } > interface eth1 { > vif eth1 { > disable: false > dr-priority: 1 > } > } > interface register_vif { > vif register_vif { > disable: false > dr-priority: 1 > } > } > bootstrap { > disable: false > cand-rp { > group-prefix 224.0.0.0/4 { > is-scope-zone: false > rp-priority: 192 > rp-holdtime: 150 > cand-rp-by-vif-name: "lo" > } > } > cand-bsr { > scope-zone 224.0.0.0/4 { > is-scope-zone: false > bsr-priority: 1 > hash-mask-len: 30 > cand-bsr-by-vif-name: "lo" > } > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > fib2mrib { > disable: false > } > } > plumbing { > mfea4 { > targetname: "MFEA_4" > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > traceoptions { > flag { > all { > disable: true > } > } > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > targetname: "fea" > } > > Shortly after startup I see on a neighbor router > > Xorp> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > 1.1.1.1 bootstrap 192 150 132 0 224.0.0.0/4 > > Xorp> show pim bootstrap > Active zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > 1.1.1.1 1 0.0.0.0 0 AcceptPreferred 26 1196 > > But after a while these entries fanish after the Timeout and SZTimeout > > However I regulary see incoming bootstrap messages from Elected BSR, so the Timeouts should be reset shouldnt they? > > [ 2005/12/16 08:45:43 TRACE xorp_pimsm4 PIM ] RX PIM_BOOTSTRAP from 192.168.4.2 to 224.0.0.13 on vif eth2 > > What am I missing? > > Thanks, > > TM > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From riccardo.sciaccaluga@tin.it" Hi! I am trying to get some information about the time xorp spend calculating the shortest path each time it does it! My intention is to insert some timestamps inside xorp code but i would like to know exactly where are the code lines implementing the shortest path calculation. Thanks in advance. From atanu@ICSI.Berkeley.EDU Fri Dec 16 17:03:29 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 16 Dec 2005 09:03:29 -0800 Subject: [Xorp-users] time performance analisys In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Fri, 16 Dec 2005 17:47:55 +0100." <18372651.1134751675429.JavaMail.root@pswm19.cp.tin.it> Message-ID: <53309.1134752609@tigger.icir.org> Hi, Look in xorp/libproto. The shortest path code is in spt.hh. There is a test program test_spt.cc. There is an example of a test graph in spt_graph1. To run the test program with the test graph: $ ./test_spt -t test5 -f spt_graph1 Atanu. >>>>> "riccardo" == riccardo writes: riccardo> Hi! I am trying to get some information about the time riccardo> xorp spend calculating the shortest path each time it does riccardo> it! My intention is to insert some timestamps inside xorp riccardo> code but i would like to know exactly where are the code riccardo> lines implementing the shortest path calculation. Thanks riccardo> in advance. riccardo> _______________________________________________ Xorp-users riccardo> mailing list Xorp-users@xorp.org riccardo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian@juniks.net Sat Dec 17 02:32:52 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 17 Dec 2005 03:32:52 +0100 Subject: [Xorp-users] IPv6 & BGP Message-ID: <20051217023252.GA28102@juniks.net> I'm having problem setting up a v6 only BGP connection. it would seem it requires a next-hop parameter which is v4. Since I don't have v4 on this machine at all it is difficult. Please advice Kristian Larsson From M.Handley@cs.ucl.ac.uk Sat Dec 17 16:43:11 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sat, 17 Dec 2005 16:43:11 +0000 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: <20051217023252.GA28102@juniks.net> References: <20051217023252.GA28102@juniks.net> Message-ID: <84a612dd0512170843y7ba76c61o46e0727f7c80f7ef@mail.gmail.com> On 12/17/05, Kristian Larsson wrote: > I'm having problem setting up a v6 only BGP > connection. it would seem it requires a next-hop > parameter which is v4. Since I don't have v4 on > this machine at all it is difficult. > Please advice The BGP spec requires a NEXTHOP attribute in all routes, and this is specified as an IPv4 address. It needs this even if you're running IPv6 only, but it shouldn't be used for the routing calculation. I've not tried it (probably Atanu has) but you should be able to specify 10.0.0.1 or something similar. - Mark From hasso@linux.ee Sat Dec 17 18:08:41 2005 From: hasso@linux.ee (Hasso Tepper) Date: Sat, 17 Dec 2005 20:08:41 +0200 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: <84a612dd0512170843y7ba76c61o46e0727f7c80f7ef@mail.gmail.com> References: <20051217023252.GA28102@juniks.net> <84a612dd0512170843y7ba76c61o46e0727f7c80f7ef@mail.gmail.com> Message-ID: <200512172008.41761.hasso@linux.ee> Mark Handley wrote: > On 12/17/05, Kristian Larsson wrote: > > I'm having problem setting up a v6 only BGP > > connection. it would seem it requires a next-hop > > parameter which is v4. Since I don't have v4 on > > this machine at all it is difficult. > > Please advice > > The BGP spec requires a NEXTHOP attribute in all routes, and this is > specified as an IPv4 address. It needs this even if you're running > IPv6 only, but it shouldn't be used for the routing calculation. I've > not tried it (probably Atanu has) but you should be able to specify > 10.0.0.1 or something similar. Sorry, but this is nonsense. >From draft-ietf-idr-rfc2858bis-07.txt (the same text is there in the RFC2858 as well): "An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute." -- Hasso Tepper From atanu@ICSI.Berkeley.EDU Sat Dec 17 18:27:51 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 17 Dec 2005 10:27:51 -0800 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: Message from Hasso Tepper of "Sat, 17 Dec 2005 20:08:41 +0200." <200512172008.41761.hasso@linux.ee> Message-ID: <81532.1134844071@tigger.icir.org> >>>>> "Hasso" == Hasso Tepper writes: Hasso> Mark Handley wrote: >> On 12/17/05, Kristian Larsson wrote: > I'm >> having problem setting up a v6 only BGP > connection. it would >> seem it requires a next-hop > parameter which is v4. Since I >> don't have v4 on > this machine at all it is difficult. > Please >> advice >> >> The BGP spec requires a NEXTHOP attribute in all routes, and this >> is specified as an IPv4 address. It needs this even if you're >> running IPv6 only, but it shouldn't be used for the routing >> calculation. I've not tried it (probably Atanu has) but you >> should be able to specify 10.0.0.1 or something similar. Hasso> Sorry, but this is nonsense. Hasso> From draft-ietf-idr-rfc2858bis-07.txt (the same text is there Hasso> in the RFC2858 as well): Hasso> "An UPDATE message that carries no NLRI, other than the one Hasso> encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the Hasso> NEXT_HOP attribute. If such a message contains the NEXT_HOP Hasso> attribute, the BGP speaker that receives the message SHOULD Hasso> ignore this attribute." Actually this is not a protocol issue but a configuration issue. In the configuration we have an IPv4 nexthop marked as a mandatory item. In the case where you want to use BGP for IPv6 only we have no way of disabling the check (yet). If you set the ipv4-unicast and ipv4-multicast flags to false and you have no local IPv4 addresses then just choose a legal IPv4 address. The IPv4 nexthop address should *not* be used it just needs to satisify the configuration constraint. I have never tried an IPv6 peering on a machine that does not have any IPv4 addresses configured but I would expect it to work. Atanu. From hasso@linux.ee Sat Dec 17 19:09:33 2005 From: hasso@linux.ee (Hasso Tepper) Date: Sat, 17 Dec 2005 21:09:33 +0200 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: <81532.1134844071@tigger.icir.org> References: <81532.1134844071@tigger.icir.org> Message-ID: <200512172109.33514.hasso@linux.ee> Atanu Ghosh wrote: > >>>>> "Hasso" == Hasso Tepper writes: > Actually this is not a protocol issue but a configuration issue. In the > configuration we have an IPv4 nexthop marked as a mandatory item. In > the case where you want to use BGP for IPv6 only we have no way of > disabling the check (yet). The need to specify next-hop explicitly in the configuration even in the IPv4 case is very strange requirement IMHO. Never seen it in any other implementation. The address used in NEXT_HOP attribute should be normally derived from interface address used for BGP session (local-ip in XORP). 5.1.3 section in draft-ietf-idr-bgp4-26 should give quite good rules for that. In case there is need to disregard these rules, modifying nexthop is job of policies. > If you set the ipv4-unicast and ipv4-multicast flags to false and you > have no local IPv4 addresses then just choose a legal IPv4 address. The > IPv4 nexthop address should *not* be used it just needs to satisify the > configuration constraint. I have never tried an IPv6 peering on a > machine that does not have any IPv4 addresses configured but I would > expect it to work. Note, that there is still need to have the IPv4 unicast address in the BGP speaker. Even RFC2858bis states: "This document assumes that any BGP speaker (including the one that supports multiprotocol capabilities defined in this document) has to have an IPv4 address (which will be used, among other things, in the AGGREGATOR attribute)." And the router id MUST be valid IPv4 unicast address as well. -- Hasso Tepper From atanu@ICSI.Berkeley.EDU Sat Dec 17 19:19:39 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 17 Dec 2005 11:19:39 -0800 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: Message from Hasso Tepper of "Sat, 17 Dec 2005 21:09:33 +0200." <200512172109.33514.hasso@linux.ee> Message-ID: <91516.1134847179@tigger.icir.org> >>>>> "Hasso" == Hasso Tepper writes: Hasso> Atanu Ghosh wrote: >> >>>>> "Hasso" == Hasso Tepper writes: Actually >> this is not a protocol issue but a configuration issue. In the >> configuration we have an IPv4 nexthop marked as a mandatory >> item. In the case where you want to use BGP for IPv6 only we have >> no way of disabling the check (yet). Hasso> The need to specify next-hop explicitly in the configuration Hasso> even in the IPv4 case is very strange requirement IMHO. Never Hasso> seen it in any other implementation. The address used in Hasso> NEXT_HOP attribute should be normally derived from interface Hasso> address used for BGP session (local-ip in XORP). 5.1.3 Hasso> section in draft-ietf-idr-bgp4-26 should give quite good Hasso> rules for that. In case there is need to disregard these Hasso> rules, modifying nexthop is job of policies. You make an excellent point. I am sorting out some BGP issues at the moment I'll try and remove the requirement to specify the nexthop. Atanu. From M.Handley@cs.ucl.ac.uk Sat Dec 17 22:32:32 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sat, 17 Dec 2005 22:32:32 +0000 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: <200512172008.41761.hasso@linux.ee> References: <20051217023252.GA28102@juniks.net> <84a612dd0512170843y7ba76c61o46e0727f7c80f7ef@mail.gmail.com> <200512172008.41761.hasso@linux.ee> Message-ID: <84a612dd0512171432i1cb903efw199df10a05abc607@mail.gmail.com> On 12/17/05, Hasso Tepper wrote: > Mark Handley wrote: > > On 12/17/05, Kristian Larsson wrote: > > > I'm having problem setting up a v6 only BGP > > > connection. it would seem it requires a next-hop > > > parameter which is v4. Since I don't have v4 on > > > this machine at all it is difficult. > > > Please advice > > > > The BGP spec requires a NEXTHOP attribute in all routes, and this is > > specified as an IPv4 address. It needs this even if you're running > > IPv6 only, but it shouldn't be used for the routing calculation. I've > > not tried it (probably Atanu has) but you should be able to specify > > 10.0.0.1 or something similar. > > Sorry, but this is nonsense. > > From draft-ietf-idr-rfc2858bis-07.txt (the same text is there in the > RFC2858 as well): > > "An UPDATE message that carries no NLRI, other than the one encoded in > the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. > If such a message contains the NEXT_HOP attribute, the BGP speaker that > receives the message SHOULD ignore this attribute." You're correct - I misremembered. I should have checked before replying. - Mark From kristian@juniks.net Sun Dec 18 23:07:27 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 19 Dec 2005 00:07:27 +0100 Subject: [Xorp-users] IPv6 & BGP In-Reply-To: <200512172109.33514.hasso@linux.ee> References: <81532.1134844071@tigger.icir.org> <200512172109.33514.hasso@linux.ee> Message-ID: <20051218230727.GA30425@juniks.net> I apologize for not responding to this earlier. On Sat, Dec 17, 2005 at 09:09:33PM +0200, Hasso Tepper wrote: > Atanu Ghosh wrote: > > >>>>> "Hasso" == Hasso Tepper writes: > > Actually this is not a protocol issue but a configuration issue. In the > > configuration we have an IPv4 nexthop marked as a mandatory item. In > > the case where you want to use BGP for IPv6 only we have no way of > > disabling the check (yet). > > The need to specify next-hop explicitly in the configuration even in the > IPv4 case is very strange requirement IMHO. Never seen it in any other > implementation. The address used in NEXT_HOP attribute should be normally > derived from interface address used for BGP session (local-ip in XORP). > 5.1.3 section in draft-ietf-idr-bgp4-26 should give quite good rules for > that. In case there is need to disregard these rules, modifying nexthop > is job of policies. Indeed it is strange. > > > If you set the ipv4-unicast and ipv4-multicast flags to false and you > > have no local IPv4 addresses then just choose a legal IPv4 address. The > > IPv4 nexthop address should *not* be used it just needs to satisify the > > configuration constraint. I have never tried an IPv6 peering on a > > machine that does not have any IPv4 addresses configured but I would > > expect it to work. > > Note, that there is still need to have the IPv4 unicast address in the BGP > speaker. Even RFC2858bis states: > > "This document assumes that any BGP speaker (including the one that > supports multiprotocol capabilities defined in this document) has to have > an IPv4 address (which will be used, among other things, in the > AGGREGATOR attribute)." > > And the router id MUST be valid IPv4 unicast address as well. The router id I can live with but do I really need v4 for anything else? After sending the mail I got it working - I had forgotten the local-ip variable. However there's still a bug here. When missing next-hop xorp will provie a clean error message however this was not the case with local-ip. I just got some mumbo-jumbo. The router is now operational and thus I cannot debug anymore with it. I intend to setup a similar scenario when I have the time but this should be pretty easy to debug.. edit protocols bgp create bgp-id 1.3.3.7 create local-as 1337 edit peer 2001::1:3:3:7 set as 1338 commit (will generate a clean error - lack of next-hop I beleive) set next-hop 1.3.3.7 commit (will genereate mumbo jumbo if I remember correctly) For the intersted this router is now announcing 2001:4db8::/32 :) Kristian. From M.Handley@cs.ucl.ac.uk Mon Dec 19 02:01:15 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 19 Dec 2005 02:01:15 +0000 Subject: [Xorp-users] XORP tutorial presentation Message-ID: <84a612dd0512181801o728c355fv290f701c2b2c341f@mail.gmail.com> I've added a powerpoint presentation covering many aspects of the design of XORP to the papers web page: http://www.xorp.org/papers.html (Please don't ask for PDF - I tried, and it came out 80MB!) - Mark From kristian@juniks.net Mon Dec 19 08:27:28 2005 From: kristian@juniks.net (Kristian Larsson) Date: Mon, 19 Dec 2005 09:27:28 +0100 Subject: [Xorp-users] Local-preference Message-ID: <20051219082728.GA27189@juniks.net> This should be real simple.. how do I see the local-preference of a route? I've tried looking at show bgp routes ipv6 unicast show bgp routes ipv6 unicast detail (which looks exactly the same as non-detailed) show route table ipv6 unicast final show route table ipv6 unicast ebgp and nowhere is localpref to find. There is a metric attribute but is it the one I'm looking for? And am I correct when I beleive that policy policy-statement test { term one { then { localpref: 120; } } } } Will set the local preference to 120? And is this only applicable at the protocols bgp level? Is it not possible to set per neighbor? Regards, Kristian From atanu@ICSI.Berkeley.EDU Mon Dec 19 09:56:52 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 19 Dec 2005 01:56:52 -0800 Subject: [Xorp-users] Local-preference In-Reply-To: Message from Kristian Larsson of "Mon, 19 Dec 2005 09:27:28 +0100." <20051219082728.GA27189@juniks.net> Message-ID: <46482.1134986212@tigger.icir.org> Hi, You can use the to clause to select a neighbour: policy { policy-statement localpref { term localpref { to { neighbour: 10.0.0.1 } then { localpref: 120 } } } } To apply this policy to BGP: protocols { bgp { export: "localpref" ... There is currently no way to discover the local-pref value that was associated with an incoming route. One way of verifying that the policy has been correctly applied is to trace all the outgoing update messages. protocol { bgp { traceoptions { flag { message-out } } ... Atanu. >>>>> "Kristian" == Kristian Larsson writes: Kristian> This should be real simple.. how do I see the Kristian> local-preference of a route? Kristian> I've tried looking at Kristian> show bgp routes ipv6 unicast Kristian> show bgp routes ipv6 unicast detail (which looks Kristian> exactly the same as non-detailed) Kristian> show route table ipv6 unicast final Kristian> show route table ipv6 unicast ebgp Kristian> and nowhere is localpref to find. There is a Kristian> metric attribute but is it the one I'm looking Kristian> for? Kristian> And am I correct when I beleive that Kristian> policy policy-statement test { Kristian> term one { Kristian> then { Kristian> localpref: 120; Kristian> } Kristian> } Kristian> } Kristian> } Kristian> Will set the local preference to 120? Kristian> And is this only applicable at the Kristian> protocols bgp Kristian> level? Is it not possible to set per neighbor? Kristian> Regards, Kristian> Kristian Kristian> _______________________________________________ Kristian> Xorp-users mailing list Kristian> Xorp-users@xorp.org Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From caddisconsulting@yahoo.com Mon Dec 19 15:19:25 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Mon, 19 Dec 2005 08:19:25 -0700 Subject: [Xorp-users] Local-preference In-Reply-To: <46482.1134986212@tigger.icir.org> Message-ID: <200512191519.jBJFJVD2014499@wyvern.icir.org> Hi Atanu, Just for additional clarification, this example will fail if entered via the command line due to XORP bug 347 (BGP export policy requires "protocol"). But I'm assuming it works if configured as part of a configuration file. Also, XORP bug 288 ("show bgp routes" commands) requests that the additional BGP prefix details, like Local Pref are provided with the "detail" option. I will add a list of the specific attributes that should be displayed, please verify after I update it (Kristian I'm adding you as a CC to the bug, I hope that's ok). -mike -----Original Message----- From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf Of Atanu Ghosh Sent: Monday, December 19, 2005 2:57 AM To: Kristian Larsson; xorp-users@xorp.org Subject: Re: [Xorp-users] Local-preference Hi, You can use the to clause to select a neighbour: policy { policy-statement localpref { term localpref { to { neighbour: 10.0.0.1 } then { localpref: 120 } } } } To apply this policy to BGP: protocols { bgp { export: "localpref" ... There is currently no way to discover the local-pref value that was associated with an incoming route. One way of verifying that the policy has been correctly applied is to trace all the outgoing update messages. protocol { bgp { traceoptions { flag { message-out } } ... Atanu. >>>>> "Kristian" == Kristian Larsson writes: Kristian> This should be real simple.. how do I see the Kristian> local-preference of a route? Kristian> I've tried looking at Kristian> show bgp routes ipv6 unicast Kristian> show bgp routes ipv6 unicast detail (which looks Kristian> exactly the same as non-detailed) Kristian> show route table ipv6 unicast final Kristian> show route table ipv6 unicast ebgp Kristian> and nowhere is localpref to find. There is a Kristian> metric attribute but is it the one I'm looking Kristian> for? Kristian> And am I correct when I beleive that Kristian> policy policy-statement test { Kristian> term one { Kristian> then { Kristian> localpref: 120; Kristian> } Kristian> } Kristian> } Kristian> } Kristian> Will set the local preference to 120? Kristian> And is this only applicable at the Kristian> protocols bgp Kristian> level? Is it not possible to set per neighbor? Kristian> Regards, Kristian> Kristian Kristian> _______________________________________________ Kristian> Xorp-users mailing list Kristian> Xorp-users@xorp.org Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian@juniks.net Mon Dec 19 16:35:11 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Mon, 19 Dec 2005 17:35:11 +0100 Subject: [Xorp-users] Local-preference In-Reply-To: <200512191519.jBJFJVD2014499@wyvern.icir.org> References: <46482.1134986212@tigger.icir.org> <200512191519.jBJFJVD2014499@wyvern.icir.org> Message-ID: <20051219163510.GA30848@juniks.net> On Mon, Dec 19, 2005 at 08:19:25AM -0700, Mike Horn wrote: > Hi Atanu, > > Just for additional clarification, this example will fail if entered via the > command line due to XORP bug 347 (BGP export policy requires "protocol"). > But I'm assuming it works if configured as part of a configuration file. This was configured from CLI. Although the policy probably does not work it never complained when I commited. I would also like a 'weight' attribute, much like on cisco so that it's possible to have a prefernce value local to the router. > Also, XORP bug 288 ("show bgp routes" commands) requests that the additional > BGP prefix details, like Local Pref are provided with the "detail" option. > I will add a list of the specific attributes that should be displayed, > please verify after I update it (Kristian I'm adding you as a CC to the bug, > I hope that's ok). That's ok! Thanks! :) Kristian. > -----Original Message----- > From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf > Of Atanu Ghosh > Sent: Monday, December 19, 2005 2:57 AM > To: Kristian Larsson; xorp-users@xorp.org > Subject: Re: [Xorp-users] Local-preference > > Hi, > > You can use the to clause to select a neighbour: > > policy { > policy-statement localpref { > term localpref { > to { > neighbour: 10.0.0.1 > } > then { > localpref: 120 > } > } > } > } > > To apply this policy to BGP: > > protocols { > bgp { > export: "localpref" > ... > > There is currently no way to discover the local-pref value that was > associated with an incoming route. > > One way of verifying that the policy has been correctly applied is to trace > all the outgoing update messages. > > protocol { > bgp { > traceoptions { > flag { > message-out > } > } > ... > > Atanu. > > >>>>> "Kristian" == Kristian Larsson writes: > > Kristian> This should be real simple.. how do I see the > Kristian> local-preference of a route? > > Kristian> I've tried looking at > Kristian> show bgp routes ipv6 unicast > Kristian> show bgp routes ipv6 unicast detail (which looks > Kristian> exactly the same as non-detailed) > > Kristian> show route table ipv6 unicast final > Kristian> show route table ipv6 unicast ebgp > > Kristian> and nowhere is localpref to find. There is a > Kristian> metric attribute but is it the one I'm looking > Kristian> for? > > Kristian> And am I correct when I beleive that > Kristian> policy policy-statement test { > Kristian> term one { > Kristian> then { > Kristian> localpref: 120; > Kristian> } > Kristian> } > Kristian> } > Kristian> } > Kristian> Will set the local preference to 120? > > Kristian> And is this only applicable at the > Kristian> protocols bgp > Kristian> level? Is it not possible to set per neighbor? > > Kristian> Regards, > Kristian> Kristian > Kristian> _______________________________________________ > Kristian> Xorp-users mailing list > Kristian> Xorp-users@xorp.org > Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From wellington@bolsistas.pop-rn.rnp.br Thu Dec 22 20:42:10 2005 From: wellington@bolsistas.pop-rn.rnp.br (wellington@bolsistas.pop-rn.rnp.br) Date: Thu, 22 Dec 2005 18:42:10 -0200 (BRST) Subject: [Xorp-users] IPv6 Multicast and XORP on Linux Message-ID: <4611.200.19.175.13.1135284130.squirrel@bolsistas.pop-rn.rnp.br> Hi, I'm using XORP on a multicast network that uses PIM-SM (too many CISCO routers !!); Few months ago I tried to run XORP on a linux machine to work as a IPv6 multicast (PIM-SM/MLD) router. It did not worked for me. I tried the USAGI patch with the latest kernel version. Kernel and XORP Compilations were ok but XORP refused to work. I'm sure that configuration is ok. IPv4 multicast runs nice. So, I wanna know.... there's a way to get XORP working with IPv6 multicast on a Linux machine? How can I do it? Thanks. Wellington Souza From pavlin@icir.org Sat Dec 24 07:22:19 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 23 Dec 2005 23:22:19 -0800 Subject: [Xorp-users] IPv6 Multicast and XORP on Linux In-Reply-To: Message from wellington@bolsistas.pop-rn.rnp.br of "Thu, 22 Dec 2005 18:42:10 -0200." <4611.200.19.175.13.1135284130.squirrel@bolsistas.pop-rn.rnp.br> Message-ID: <200512240722.jBO7MJ3N024113@possum.icir.org> > I'm using XORP on a multicast network that uses PIM-SM (too many CISCO > routers !!); > > Few months ago I tried to run XORP on a linux machine to work as a IPv6 > multicast (PIM-SM/MLD) router. It did not worked for me. I tried the USAGI > patch with the latest kernel version. Kernel and XORP Compilations were ok > but XORP refused to work. I'm sure that configuration is ok. IPv4 > multicast runs nice. > > So, I wanna know.... there's a way to get XORP working with IPv6 multicast > on a Linux machine? How can I do it? Can you be more specific what exactly doesn't work? Same question has been asked recently on the list. See the following email about a brief summary of the current status: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-November/000901.html Pavlin From abazh18@gmail.com Fri Dec 30 06:36:47 2005 From: abazh18@gmail.com (abazh) Date: Fri, 30 Dec 2005 13:36:47 +0700 Subject: [Xorp-users] Re: Need help for compiling xorp from current cvs on Linux (IPv6 Multicast) In-Reply-To: <200512132254.jBDMsuur088892@possum.icir.org> References: <438279e60512082216hb86399dta33a15b960ee77c1@mail.gmail.com> <200512132254.jBDMsuur088892@possum.icir.org> Message-ID: <438279e60512292236h2fa4af5bgaf70c254e96ef9fd@mail.gmail.com> ------=_Part_13711_23349009.1135924607395 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Pavlin, I have tried to compile and install XORP successfully. THe xorp could joint to another XORP (running on BSD), but unfortunately when I try to run multicast client behind XORP(on linux) and the multicast client beginning to receive multicast packets, the XORP then died. I do not know what's wrong, perhaps you could help. Here what I got from log file: 2/30 14:27:42 WARNING xorp_pimsm6 XrlPimTarget ] Handling method for mld6igmp_client/0.1/delete_membership6 failed: XrlCmdError 102 Command failed Failed to delete membership for (::, ff02::2) [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed [ 2005/12/30 14:27:42 INFO xorp_pimsm6 XRL ] Sender died (protocol =3D "stc= p", address =3D "127.0.0.1:32813") [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 LIBXORP +211 buffered_asyncio.cc io_event ] read error 111 [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error =3D 111) [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed [ 2005/12/30 14:27:42 ERROR xorp_pimsm6:2707 PIM +2145 xrl_pim_node.cc mfea_client_send_add_delete_dataflow_monitor_cb ] XRL communication error: 201 Resolve failed rlFinderTarget +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 "MFEA_6" does not exist or is not enabled. [ 2005/12/30 14:27:42 WARNING xorp_rtrmgr:2670 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 "MFEA_6" does not exist or is not enabled. [ 2005/12/30 14:27:42 WARNING xorp_rtrmgr:2670 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 "MFEA_6" does not exist or is not enabled. abazh On 12/14/05, Pavlin Radoslavov wrote: > > > I use gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) > > All gcc-4.0.2 compilation problems should now be fixed in CVS. The > last commit just went in so make sure that you have a recent > checkout tree with the following file revisions: > > libxorp/callback-gen.py rev 1.15 > libxorp/callback_debug.hh rev. 1.10 > libxorp/callback_nodebug.hh rev. 1.8 > > Pavlin > > P.S. There is already bugzilla entry about those gcc-4.0.2 > compilation errors, so please use that entry if there are any other > similar issues: > > http://www.xorp.org/bugzilla/show_bug.cgi?id=3D414 > > > > > After trying to compile again, I got not as in previous, but got > > another following errors: > > > > source=3D'ifconfig_get_getifaddrs.cc' > > object=3D'ifconfig_get_getifaddrs.lo' libtool=3Dyes \ > > depfile=3D'.deps/ifconfig_get_getifaddrs.Plo' > > tmpdepfile=3D'.deps/ifconfig_get_getifaddrs.TPlo' \ > > depmode=3Dgcc3 /bin/sh ../config/depcomp \ > > /bin/sh ../libtool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I.. > > -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror > > -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 > > -pipe -c -o ifconfig_get_getifaddrs.lo `test -f > > ifconfig_get_getifaddrs.cc || echo './'`ifconfig_get_getifaddrs.cc > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > > -ftemplate-depth-25 -pipe -c ifconfig_get_getifaddrs.cc -MT > > ifconfig_get_getifaddrs.lo -MD -MP -MF > > .deps/ifconfig_get_getifaddrs.TPlo -o ifconfig_get_getifaddrs.o > > cc1plus: warnings being treated as errors > > ifconfig_get_getifaddrs.cc: In member function 'bool > > IfConfigGetGetifaddrs::read_config(IfTree&)': > > ifconfig_get_getifaddrs.cc:108: warning: cast from type 'ifaddrs**' to > > type 'const ifaddrs**' casts away constness > > make[3]: *** [ifconfig_get_getifaddrs.lo] Error 1 > > make[3]: Leaving directory `/usr/local/xorp/src/xorp/fea' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/usr/local/xorp/src/xorp/fea' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/usr/local/xorp/src/xorp' > > make: *** [all] Error 2 > > > > > > On 12/9/05, Pavlin Radoslavov wrote: > > > > As I follow previous discussion on IPv6 Multicast routing on Iinux, > I have > > > > tried to patch the linux kernel. > > > > I use fedore core 4 with USAGI linux kernel 2.6.14. > > > > > > What is the compiler version (g++ --version)? > > > > > > Anyway, I think I found the problem and committed it to CVS > > > (libproto/proto_node.hh rev 1.33). > > > > > > Pavlin > > > > > > > > > > > > > > My problem is when trying to compile xorp it self, I got below > errors: > > > > Making all in . > > > > gmake[3]: Entering directory `/root/xorp/cli' > > > > source=3D3D'cli_client.cc' object=3D3D'cli_client.lo' libtool=3D3Dy= es \ > > > > depfile=3D3D'.deps/cli_client.Plo' > tmpdepfile=3D3D'.deps/cli_client.TPlo' \ > > > > depmode=3D3Dgcc3 /bin/sh ../config/depcomp \ > > > > /bin/sh ../libtool --mode=3D3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -= I.. > -I.. > > > > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith > > > -Wcast-alig=3D > > > > n > > > > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_client.lo > `test > > > -f > > > > cli_client.cc || echo './'`cli_client.cc > > > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > > > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align > -Woverloaded-virtual > > > > -ftemplate-depth-25 -pipe -c cli_client.cc -MT cli_client.lo -MD -M= P > -MF > > > > .deps/cli_client.TPlo -o cli_client.o > > > > ../libproto/proto_node.hh: In member function 'uint32_t > > > > ProtoNode::vif_name2vif_index(const std::string&) const': > > > > ../libproto/proto_node.hh:727: error: no matching function for call > to > > > > 'find(std::_Rb_tree_const_iterator std::basic_string > > > std::char_traits, std::allocator >, unsigned int> >&)' > > > > gmake[3]: *** [cli_client.lo] Error 1 > > > > gmake[3]: Leaving directory `/root/xorp/cli' > > > > gmake[2]: *** [all-recursive] Error 1 > > > > gmake[2]: Leaving directory `/root/xorp/cli' > > > > gmake[1]: *** [all-recursive] Error 1 > > > > gmake[1]: Leaving directory `/root/xorp' > > > > gmake: *** [all] Error 2 > > > > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users@xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > ------=_Part_13711_23349009.1135924607395 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Pavlin,

I have tried to compile and install XORP successfully.
THe xorp could joint to another XORP (running on BSD), but unfortunately when I try to run multicast client behind XORP(on linux) and  the multicast client beginning to receive multicast packets, the XORP then died.

I do not know what's wrong, perhaps you could help.

Here what I got from log file:

2/30 14:27:42 WARNING xorp_pimsm6 XrlPimTarget ] Handling method for mld6igmp_client/0.1/delete_membership6 failed: XrlCmdError 102 Command failed Failed to delete membership for (::, ff02::2)
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed
[ 2005/12/30 14:27:42 INFO xorp_pimsm6 XRL ] Sender died (protocol =3D &quo= t;stcp", address =3D "127.0.0.= 1:32813")
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 LIBXORP +211 buffered_as= yncio.cc io_event ] read error 111
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 XRL +783 xrl_pf_stcp.cc = read_event ] Read failed (error =3D 111)
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 XRL +636 xrl_pf_stcp.cc = die ] XrlPFSTCPSender died: read error
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 PIM +2633 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed
[ 2005/12/30 14:27:42  ERROR xorp_pimsm6:2707 PIM +2145 xrl_pim_node.cc mfea_client_send_add_delete_dataflow_monitor_cb ] XRL communication error: 201 Resolve failed
rlFinderTarget +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 "MFEA_6" does not exist or is not enabled.
[ 2005/12/30 14:27:42  WARNING xorp_rtrmgr:2670 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 "MFEA_6" does not exist or is not enabled.<= br> [ 2005/12/30 14:27:42  WARNING xorp_rtrmgr:2670 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 "MFEA_6" does not exist or is not enabled.<= br>

abazh

On 12/14/05, Pavlin Radoslavov <pavlin@ic= ir.org> wrote:
> I use gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)

All gcc-4.0.= 2 compilation problems should now be fixed in CVS. The
last commit just = went in so make sure that you have a recent
checkout tree with the follo= wing file revisions:

libxorp/callback-gen.py rev 1.15
libxorp/callback_debug.hh rev. = 1.10
libxorp/callback_nodebug.hh rev. 1.8

Pavlin

P.S. Ther= e is already bugzilla entry about those gcc-4.0.2
compilation errors, so= please use that entry if there are any other
similar issues:

http://www.xorp.org/bugzilla/show_bug.cgi?id=3D414
>
> After trying to compile again, I got not as in previous, but= got
> another following errors:
>
> source=3D'ifconfig_get_g= etifaddrs.cc'
> object=3D'ifconfig_get_getifaddrs.lo' libtool=3Dyes \=
> depfile=3D'.deps/ifconfig_get_getifaddrs.Plo'
> tmpdepfile= =3D'.deps/ifconfig_get_getifaddrs.TPlo' \
> depmode=3Dgcc3 /bin/sh ../config/depcomp \
> /bin/sh ../libt= ool --mode=3Dcompile g++ -DHAVE_CONFIG_H -I. -I. -I..
> -I.. &nb= sp;  -g -W -Wall -Wwrite-strings -Wcast-qual -Werror
> -Wpo= inter-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25
> -pipe -c -o ifconfig_get_getifaddrs.lo `test -f
> ifconfig_g= et_getifaddrs.cc || echo './'`ifconfig_get_getifaddrs.cc
> g++ -DHAVE= _CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings
> -Wcast-qual= -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual
> -ftemplate-depth-25 -pipe -c ifconfig_get_getifaddrs.cc -MT
>= ; ifconfig_get_getifaddrs.lo -MD -MP -MF
> .deps/ifconfig_get_getifad= drs.TPlo -o ifconfig_get_getifaddrs.o
> cc1plus: warnings being treat= ed as errors
> ifconfig_get_getifaddrs.cc: In member function 'bool
> IfCon= figGetGetifaddrs::read_config(IfTree&)':
> ifconfig_get_getifaddr= s.cc:108: warning: cast from type 'ifaddrs**' to
> type 'const ifaddr= s**' casts away constness
> make[3]: *** [ifconfig_get_getifaddrs.lo] Error 1
> make[3]:= Leaving directory `/usr/local/xorp/src/xorp/fea'
> make[2]: *** [all= -recursive] Error 1
> make[2]: Leaving directory `/usr/local/xorp/src= /xorp/fea'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving dire= ctory `/usr/local/xorp/src/xorp'
> make: *** [all] Error 2
>>
> On 12/9/05, Pavlin Radoslavov < pavlin@icir.org> wrote:
> > > As I follow previous discu= ssion on IPv6 Multicast routing on Iinux, I have
> > > tried to= patch the linux kernel.
> > > I use fedore core 4 with USAGI l= inux kernel=20 2.6.14.
> >
> > What is the compiler version (g++ --versi= on)?
> >
> > Anyway, I think I found the problem and comm= itted it to CVS
> > (libproto/proto_node.hh rev 1.33).
> >= ;
> > Pavlin
> >
> >
> > >
> &g= t; > My problem is when trying to compile xorp it self, I got below erro= rs:
> > > Making all in .
> > > gmake[3]: Entering = directory `/root/xorp/cli'
> > > source=3D3D'cli_client.cc' object=3D3D'cli_client.lo' li= btool=3D3Dyes \
> > > depfile=3D3D'.deps/cli_client.Plo' tmpdep= file=3D3D'.deps/cli_client.TPlo' \
> > > depmode=3D3Dgcc3 /bin/= sh ../config/depcomp \
> > > /bin/sh ../libtool --mode=3D3Dcompile g++ -DHAVE_CONFIG_= H -I. -I. -I.. -I..
> > > -g -W -Wall -Wwrite-strings -Wcast-qu= al -Werror -Wpointer-arith
> > -Wcast-alig=3D
> > > n<= br> > > > -Woverloaded-virtual -ftemplate-depth-25 -pipe -c -o cli_cli= ent.lo `test
> > -f
> > > cli_client.cc || echo './'`c= li_client.cc
> > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W = -Wall -Wwrite-strings
> > > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverl= oaded-virtual
> > > -ftemplate-depth-25 -pipe -c cli_client.cc = -MT cli_client.lo -MD -MP -MF
> > > .deps/cli_client.TPlo -o cl= i_client.o
> > > ../libproto/proto_node.hh: In member function 'uint32_t<= br>> > > ProtoNode<V>::vif_name2vif_index(const std::string&= amp;) const':
> > > ../libproto/proto_node.hh:727: error: no ma= tching function for call to
> > > 'find(std::_Rb_tree_const_iterator<std::pair<const= std::basic_string<char,
> > > std::char_traits<char>,= std::allocator<char> >, unsigned int> >&)'
> >= > gmake[3]: *** [cli_client.lo] Error 1
> > > gmake[3]: Leaving directory `/root/xorp/cli'
> >= ; > gmake[2]: *** [all-recursive] Error 1
> > > gmake[2]: Le= aving directory `/root/xorp/cli'
> > > gmake[1]: *** [all-recur= sive] Error 1
> > > gmake[1]: Leaving directory `/root/xorp'
> > &g= t; gmake: *** [all] Error 2
> >
>
> __________________= _____________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/list= info/xorp-users


------=_Part_13711_23349009.1135924607395-- From ahthamrin@gmail.com Fri Dec 30 06:54:04 2005 From: ahthamrin@gmail.com (Achmad Husni Thamrin) Date: Fri, 30 Dec 2005 15:54:04 +0900 Subject: [Xorp-users] XORP SNMP module status? Message-ID: <4250f3610512292254q1662dcf7l1bfa77b34f6d7d07@mail.gmail.com> Dear All, I'd like to know the current status of the SNMP module. http://xorp.org/status.html says the the module is found to be broken before Release 1.1. Thank you. -- http://lo1.sytes.net/ From atanu@ICSI.Berkeley.EDU Fri Dec 30 22:26:16 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 30 Dec 2005 14:26:16 -0800 Subject: [Xorp-users] XORP SNMP module status? In-Reply-To: Message from Achmad Husni Thamrin of "Fri, 30 Dec 2005 15:54:04 +0900." <4250f3610512292254q1662dcf7l1bfa77b34f6d7d07@mail.gmail.com> Message-ID: <58190.1135981576@tigger.icir.org> The version in cvs works. Atanu. >>>>> "Achmad" == Achmad Husni Thamrin writes: Achmad> Dear All, I'd like to know the current status of the SNMP Achmad> module. http://xorp.org/status.html says the the module is Achmad> found to be broken before Release 1.1. Achmad> Thank you. -- http://lo1.sytes.net/ Achmad> _______________________________________________ Xorp-users Achmad> mailing list Xorp-users@xorp.org Achmad> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users