From atanu at ICSI.Berkeley.EDU Wed Aug 2 16:37:32 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 02 Aug 2006 16:37:32 -0700 Subject: [Xorp-users] Announcing XORP Release 1.3 Message-ID: <75907.1154561852@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.3 Release, which is now available from . The major new features with this release are: * IGMPv3 (RFC 3376) * MLDv2 (RFC 3810) In addition, this release contains numerous bug fixes. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.4 release; these are documented in the XORP Bugzilla database . In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users at xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback at xorp.org. - The XORP Team P.S. Release notes are included below. ------------------------------------------------------------------ XORP RELEASE NOTES This file contains XORP release notes (most recent releases first). Release 1.3 (2006/08/02) ========================= ALL: - Numerous improvements, bug fixes and cleanup. - XORP now builds on Linux Fedora Core5, DragonFlyBSD-1.4, FreeBSD-6.1. - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810). Those are necessary to complete the Source-Specific Multicast support. CONFIGURATION: - Addition of new OSPF configuration statement as part of the MD5 keys: * max-time-drift: u32 (default to 3600, i.e., 1 hour) It is used to set the maximum time drift (in seconds) among all OSPF routers. The allowed values are in the range [0--65535]. If the value is 65535, the time drift is unlimited. - The following statements for configuring static routes have been deprecated: route4, route6, interface-route4, interface-route6, mrib-route4, mrib-route6, mrib-interface-route4, mrib-interface-route6. The new replacement statements are: route, interface-route, mrib-route, mrib-interface-route. Each of the new statements can be used to configure either IPv4Net or IPv6Net route. - The following statements for configuring RIP and RIPng have been renamed: * route-expiry-secs -> route-timeout * route-deletion-secs -> deletion-delay * table-request-secs -> request-interval * interpacket-delay-msecs -> interpacket-delay - The following statements for configuring RIP and RIPng random intervals have been replaced: * triggered-update-min-secs and triggered-update-max-secs with triggered-delay and triggered-jitter * table-announce-min-secs and table-announce-max-secs with update-interval and update-jitter Previously, each interval was specified as [foo-min, foo-max]. Now each interval is specified as [foo - foo * jitter / 100, foo + foo * jitter / 100] where "jitter" is specified as a percentage (an integer in the interval [0, 100]) of the value of "foo". - The "version" statement for configuring an IGMP interface/vif allows values in the range [1-3]. Previously, the allowed range was [1-2]. - The "version" statement for configuring a MLD interface/vif allows values in the range [1-2]. Previously, the allowed range was [1-1]. - The following statement for configuring PIM-SM (pimsm4 and pimsm6) has been renamed: interval-sec -> interval - If a "then" policy block contains "accept" or "reject" statement, now all statements inside the "then" block are evaluated regardless of their position. - Addition of a new "exit" operational mode command that is equivalent to the "quit" operational mode command. - The "create" and "set" configuration commands are merged, so now the new "set" command can be used for setting values and for creating new configuration nodes. For backward compatibility, the obsoleted "create" command is preserved as an alias for the new "set" command, though it may be removed in the future. LIBXORP: - Few bug fixes in the RefTrie implementation. LIBXIPC: - Minor improvement in parsing XRL requests. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Various bug fixes. XORPSH: - Previously, the "commit" command was not available in configuration mode if there were no pending configuration changes. Now the "commit" command is always available, but the following message will be printed instead: "No configuration changes to commit." - Various bug fixes. POLICY: - Various bug fixes. FEA/MFEA: - Bug fix in transmitting large packets on Linux when using IP raw sockets. - Linux-related netlink socket code refactoring and bug fix. - Bug fix in obtaining the incoming interface for raw packets (in case of *BSD). - Bug fix in parsing the ancillary data from recvmsg(). - Accept zeroed source addresses of raw packets, because of protocols like IGMPv3. - Bug fix in restoring kernel routes that were automatically removed when the MAC address or MTU on an interface is modified. - Bug fix in processing IPv4 raw packets if they contain an IP option with a bogus option length. RIB: - Several bug fixes and improvements. RIP: - Various bug fixes in the MD5 authentication support. - Remove route flap when applying/deleting RIP-related import policies. - Fix an issue with INFINITY cost routes that might be bounced indefinitely between two XORP routers. OSPF: - Various bug fixes in the MD5 authentication support. BGP: - Prefix limits on a per peer basis. - Various bug fixes. STATIC_ROUTES: - No significant changes. MLD/IGMP: - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810). - Unification of the IGMP and MLD execution path. PIM-SM: - Bug fix related to the SPT switch (the bug is *BSD specific). - Use the RPF interface toward the BSR when transmitting a Cand-RP Advertisement message. Previously the first interface that is UP was chosen. - Use the RPF interface toward the RP when transmitting PIM Register messages toward the RP. Previously the interface of the directly connected source was chosen. FIB2MRIB: - No significant changes. CLI: - Bug fix related to tracking the window size when it is resized. SNMP: - No significant changes. From rm at ib-caddy.si Thu Aug 3 06:59:05 2006 From: rm at ib-caddy.si (Robert M.) Date: Thu, 03 Aug 2006 15:59:05 +0200 Subject: [Xorp-users] iptv and multicast forwarding (newbie) Message-ID: <44D20129.6070809@ib-caddy.si> Hello Guys, For a start, here is my home network configuration: - linux box runing FC5 - wan connected to eth1 - vlan interface eth1.8 (1*) - lan switch connected to eth0 - few lan PCs (max 4) connected to lan switch Besides internet access, my ISP is also providing iptv multicast service. (1*) I figured out they setup vlan with an id 8 for iptv service, so I added vlan interface eth1.8. With this setup I can watch tv on linux box (VLC). Now, I want to forward multicast traffic to lan clients (eth0). I wonder if someone can help me with config.boot? What interfaces/protocols must I include? Do I need PIM-SM in described scenario? It would be great if someone can post template config.boot for similar scenarion. Any help will be greatly appreciated. Robert M. From steve.eckmann.ctr at mda.mil Thu Aug 3 05:57:38 2006 From: steve.eckmann.ctr at mda.mil (Eckmann, Steve CTR MDA/IC) Date: Thu, 3 Aug 2006 06:57:38 -0600 Subject: [Xorp-users] malformed PIM REGISTER messages? Message-ID: <77BF8C8851DE034EA109FF82EE622A450147983C@USCEN-MAIL.uscentral.mda.mil> I am tunneling multicast between a Cisco router and a Linux/XORP router, using PIM-SM. If the RP is on the XORP router everything works. If the RP is on the Cisco router then mcast receivers attached to the XORP router can receive traffic sent from hosts on the Cisco side of the tunnel, but mcast receivers on the Cisco side do not receive mcast traffic sent by hosts on the XORP side. Ethereal running on an intermediate router or on the Linux/XORP router reports that the (GRE-wrapped) PIM REGISTER messages sent by XORP are "Malformed", and no encapsulated UDP datagram appears in the Ethereal display. The Cisco router appears to immediately send a PIM REGISTER_STOP instead of sending a JOIN_PRUNE when it receives one of these PIM REGISTER messages. So it looks like there might be something wrong with the PIM REGISTER messages. Any suggestions about what might cause this symptom? I'm running Fedora Core 4 Linux with XORP 1.2 (also tried the 1.3 Release Candidate; I see that official 1.3 became available yesterday...). Thanks. Steve From venkthi1 at iit.edu Thu Aug 3 18:44:28 2006 From: venkthi1 at iit.edu (Venketesan) Date: Thu, 03 Aug 2006 18:44:28 -0700 Subject: [Xorp-users] Looping back PIM messages Message-ID: <3479dec3476e69.3476e693479dec@iit.edu> Hey all, I am writing a multicast tunneling protocol in linux redhat 9. I have a program that receives encapsulated PIm control messages on an interface that basically connects to a non multicast router. The topology is the following A---->0B1----->C A is a non xorp linux box. B is a xorp linux box with my code running in it too. C is a pure XORP linux box. I receive unicast encapsulated PIM control messages in B via A. My code receves thise control messages and decapsulates and sends them to C. I send these PIM-SM packets using a raw socket binded to IP address of interface 1 in B. Now the issue is for some reason my program receves all the PIM control messages back that it was supposed to send out. Xorp is looping it back and not letting the packets go out of interface1 in B. If i stop xorp everything is fine and the packets are received at C. Note that i am not listening over any raw socket just sending PIM-SM packets using them. The way i receive is in the kernel i intercept PIM- SM packets, make a copy of the same and pass it to my user space program using netlink sockets. Can anyone guide me on this issue, is it a expected behaviour of XORP to loop back any PIM-SM control packet not orginated by itself. I am using XORP 1.2 regards, Venkat From venkthi1 at iit.edu Thu Aug 3 21:54:44 2006 From: venkthi1 at iit.edu (Venketesan) Date: Thu, 03 Aug 2006 21:54:44 -0700 Subject: [Xorp-users] Looping back PIM messages Message-ID: <3488af83484234.34842343488af8@iit.edu> I am sorry, i noticed in fact that the PIm control messages do go out of the interface 1 in router B, but i still dont know why they are also looped back to me when XORP is running. Thanks a lot. venkat ----- Original Message ----- From: Venketesan Date: Thursday, August 3, 2006 6:44 pm Subject: [Xorp-users] Looping back PIM messages > Hey all, > > I am writing a multicast tunneling protocol in linux redhat 9. I > have > a program that > receives encapsulated PIm control messages on an interface that > basically connects to a non multicast router. > The topology is the following > A---->0B1----->C > > A is a non xorp linux box. > B is a xorp linux box with my code running in it too. > C is a pure XORP linux box. > > I receive unicast encapsulated PIM control messages in B via A. My > code > receves thise control messages and decapsulates and sends them to > C. I > send these PIM-SM packets using a raw socket binded to IP address > of > interface 1 in B. > > Now the issue is for some reason my program receves all the PIM > control messages back that it was supposed to send out. Xorp is > looping it back and not letting the packets go out of interface1 > in B. > If i > stop xorp everything is fine and the packets are received at C. > Note that i am not listening over any raw socket just sending PIM- > SM > packets using them. The way i receive is in the kernel i intercept > PIM- > SM packets, make a copy of the same and pass it to my user space > program using netlink sockets. > > Can anyone guide me on this issue, is it a expected behaviour of > XORP > to loop back any PIM-SM control packet not orginated by itself. > I am using XORP 1.2 > regards, > Venkat > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin at icir.org Mon Aug 7 12:49:35 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 12:49:35 -0700 Subject: [Xorp-users] iptv and multicast forwarding (newbie) In-Reply-To: Message from "Robert M." of "Thu, 03 Aug 2006 15:59:05 +0200." <44D20129.6070809@ib-caddy.si> Message-ID: <200608071949.k77JnZFY072302@possum.icir.org> > For a start, here is my home network configuration: > > - linux box runing FC5 > - wan connected to eth1 > - vlan interface eth1.8 (1*) > - lan switch connected to eth0 > - few lan PCs (max 4) connected to lan switch > > Besides internet access, my ISP is also providing iptv multicast > service. (1*) I figured out they setup vlan with an id 8 for iptv > service, so I added vlan interface eth1.8. With this setup I can watch > tv on linux box (VLC). Now, I want to forward multicast traffic to lan > clients (eth0). I wonder if someone can help me with config.boot? What > interfaces/protocols must I include? Do I need PIM-SM in described > scenario? It would be great if someone can post template config.boot for > similar scenarion. If the ISP doesn't allow you to connect your PIM-SM router to its PIM-SM domain (probably the most likely scenario), then your PIM-SM router won't be able to do much for you. For example, if the ISP rejects your PIM-SM Join messages, then the LAN clients on eth0 can receive traffic for a multicast group, ONLY if there is a receiver on the vlan interface for the same group. Eventually, you need an IGMP proxy to get around the problem: http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-06.txt Unfortunately, XORP doesn't implement (yet) the IGMP proxy mechanism, and I am not aware of any open-source IGMP proxy implementation. Anyway, below is a sample template you could use to configure XORP as a PIM-SM router (and RP). Few notes about the configuration: * You must replace with the IP address of eth0 or eth1.8 * I have commented-out running IGMP on eth1.8 to avoid any IGMP-related issues (in case your ISP is not filtering the IGMP Query messages from your router). However, if you have senders on eth0 and receivers on eth1, then you need to run IGMP on eth1.8 * The dr-priority on eth1.8 is set to a very low value to avoid any PIM-SM related issues (in case your ISP is not filtering the PIM-SM messages from your router). * The router is configured as a static RP, but practically it will be an RP only for your network. * Again, note that with this setup, you MUST join the same group on both eth1.8 and eth0 if you want to receive the data traffic on eth0. However, if your ISP actually allows your PIM-SM router to connect to their PIM-SM domain, then you can reuse the setup below with the following modifications: * Enable IGMP on interface eth1.8 * Comment the "static-rps" section. Hope that helps, Pavlin interfaces { interface eth0 { default-system-config } interface eth1.8 { default-system-config } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { interface eth0 { vif eth0 { disable: false } } interface eth1.8 { vif eth1.8 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { interface eth0 { vif eth0 { disable: false } } /* interface eth1.8 { vif eth1.8 { disable: false } } */ traceoptions { flag all { disable: false } } } } protocols { pimsm4 { interface eth0 { vif eth0 { disable: false } } interface eth1.8 { vif eth1.8 { disable: false dr-priority: 250 } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp { group-prefix 224.0.0.0/4 { rp-priority: 250 hash-mask-len: 30 } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } From pavlin at icir.org Mon Aug 7 12:58:41 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 12:58:41 -0700 Subject: [Xorp-users] iptv and multicast forwarding (newbie) In-Reply-To: Message from Pavlin Radoslavov of "Mon, 07 Aug 2006 12:49:35 PDT." <200608071949.k77JnZFY072302@possum.icir.org> Message-ID: <200608071958.k77JwfXQ072444@possum.icir.org> > However, if your ISP actually allows your PIM-SM router to connect > to their PIM-SM domain, then you can reuse the setup below with the > following modifications: > > * Enable IGMP on interface eth1.8 > * Comment the "static-rps" section. Small correction for the second bullet: it assumes that your ISP is running the Bootstrap mechanism. If this is not the case, then you need to keep that section, but use instead the IP address of the Cand-RP inside your ISP domain. If your ISP has more than one Cand-RPs, then you need to add "rp" entries for each Cand-RP. Of course, all this requires obtaining that information from your ISP, and they might not be willing giving it out to you :) Pavlin From pavlin at icir.org Mon Aug 7 15:42:54 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 15:42:54 -0700 Subject: [Xorp-users] iptv and multicast forwarding (newbie) In-Reply-To: Message from Pavlin Radoslavov of "Mon, 07 Aug 2006 12:49:35 PDT." <200608071949.k77JnZFY072302@possum.icir.org> Message-ID: <200608072242.k77MgsWv073826@possum.icir.org> > * The dr-priority on eth1.8 is set to a very low value to avoid any > PIM-SM related issues (in case your ISP is not filtering the > PIM-SM messages from your router). The above is incorrect. The "dr-priority" in the example was set to 250, which is actually very high priority. It should have been set to "0". Pavlin > interfaces { > interface eth0 { > default-system-config > } > interface eth1.8 { > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > plumbing { > mfea4 { > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1.8 { > vif eth1.8 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > interface eth0 { > vif eth0 { > disable: false > } > } > /* > interface eth1.8 { > vif eth1.8 { > disable: false > } > } > */ > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1.8 { > vif eth1.8 { > disable: false > dr-priority: 250 > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > static-rps { > rp { > group-prefix 224.0.0.0/4 { > rp-priority: 250 > hash-mask-len: 30 > } > } > } > switch-to-spt-threshold { > disable: false > interval: 100 > bytes: 102400 > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > fib2mrib { > disable: false > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Mon Aug 7 15:56:45 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 15:56:45 -0700 Subject: [Xorp-users] malformed PIM REGISTER messages? In-Reply-To: Message from "Eckmann, Steve CTR MDA/IC" of "Thu, 03 Aug 2006 06:57:38 MDT." <77BF8C8851DE034EA109FF82EE622A450147983C@USCEN-MAIL.uscentral.mda.mil> Message-ID: <200608072256.k77MujfF073976@possum.icir.org> > I am tunneling multicast between a Cisco router and a Linux/XORP > router, using PIM-SM. If the RP is on the XORP router everything > works. If the RP is on the Cisco router then mcast receivers > attached to the XORP router can receive traffic sent from hosts on > the Cisco side of the tunnel, but mcast receivers on the Cisco > side do not receive mcast traffic sent by hosts on the XORP > side. Ethereal running on an intermediate router or on the > Linux/XORP router reports that the (GRE-wrapped) PIM REGISTER > messages sent by XORP are "Malformed", and no encapsulated UDP > datagram appears in the Ethereal display. The Cisco router appears > to immediately send a PIM REGISTER_STOP instead of sending a > JOIN_PRUNE when it receives one of these PIM REGISTER messages. So > it looks like there might be something wrong with the PIM REGISTER > messages. > > Any suggestions about what might cause this symptom? I'm running > Fedora Core 4 Linux with XORP 1.2 (also tried the 1.3 Release > Candidate; I see that official 1.3 became available > yesterday...). Unfortunately, I don't have access to a Cisco router to try to replicate your setup. Can you run tcpdump instead and test whether you see similar "malformed" message. If "yes", could you send me the content of that malformed packet. Also, what is the Linux distribution and kernel version you are using? Could somebody on the list confirm that they have been successful with PIM Registers transmitted by XORP and received by Cisco (with or without GRE). Thanks, Pavlin From pavlin at icir.org Mon Aug 7 16:06:02 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 Aug 2006 16:06:02 -0700 Subject: [Xorp-users] Looping back PIM messages In-Reply-To: Message from Venketesan of "Thu, 03 Aug 2006 21:54:44 PDT." <3488af83484234.34842343488af8@iit.edu> Message-ID: <200608072306.k77N62EZ074134@possum.icir.org> > I am sorry, i noticed in fact that the PIm control messages do go out > of the interface 1 in router B, but i still dont know why they are > also looped back to me when XORP is running. Yes, this is the expected behavior, because the IP_MULTICAST_LOOP flag is explicitly set before transmitting the multicast packets. E.g., see the following code inside fea/mfea_proto_comm.cc, ProtoComm::proto_socket_write(): if (dst.is_multicast()) { set_default_multicast_vif(mfea_vif->vif_index()); set_multicast_loop(true); setloop = true; } Hence, in your code you would have to explicitly ignore your own control messages. E.g., see the following code inside pim/pim_vif.cc PimVif::pim_process(): // Ignore my own PIM messages if (pim_node().is_my_addr(src)) return (XORP_ERROR); If for whatever reason you cannot perform such check, then you can try to comment-out the "set_multicast_loop(true)" statement inside fea/mfea_proto_comm.cc. Pavlin > Thanks a lot. > > venkat > > ----- Original Message ----- > From: Venketesan > Date: Thursday, August 3, 2006 6:44 pm > Subject: [Xorp-users] Looping back PIM messages > > > Hey all, > > > > I am writing a multicast tunneling protocol in linux redhat 9. I > > have > > a program that > > receives encapsulated PIm control messages on an interface that > > basically connects to a non multicast router. > > The topology is the following > > A---->0B1----->C > > > > A is a non xorp linux box. > > B is a xorp linux box with my code running in it too. > > C is a pure XORP linux box. > > > > I receive unicast encapsulated PIM control messages in B via A. My > > code > > receves thise control messages and decapsulates and sends them to > > C. I > > send these PIM-SM packets using a raw socket binded to IP address > > of > > interface 1 in B. > > > > Now the issue is for some reason my program receves all the PIM > > control messages back that it was supposed to send out. Xorp is > > looping it back and not letting the packets go out of interface1 > > in B. > > If i > > stop xorp everything is fine and the packets are received at C. > > Note that i am not listening over any raw socket just sending PIM- > > SM > > packets using them. The way i receive is in the kernel i intercept > > PIM- > > SM packets, make a copy of the same and pass it to my user space > > program using netlink sockets. > > > > Can anyone guide me on this issue, is it a expected behaviour of > > XORP > > to loop back any PIM-SM control packet not orginated by itself. > > I am using XORP 1.2 > > regards, > > Venkat > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From venkthi1 at iit.edu Mon Aug 7 16:21:02 2006 From: venkthi1 at iit.edu (Venketesan) Date: Mon, 07 Aug 2006 16:21:02 -0700 Subject: [Xorp-users] Looping back PIM messages Message-ID: <35ae76135abbce.35abbce35ae761@iit.edu> Thanks for clarifying that it was an expected behaviour. I did put in a check to ignore my own packets . regards, Venkat ----- Original Message ----- From: Pavlin Radoslavov Date: Monday, August 7, 2006 4:06 pm Subject: Re: [Xorp-users] Looping back PIM messages > > I am sorry, i noticed in fact that the PIm control messages do > go out > > of the interface 1 in router B, but i still dont know why they > are > > also looped back to me when XORP is running. > > Yes, this is the expected behavior, because the IP_MULTICAST_LOOP > flag is explicitly set before transmitting the multicast packets. > E.g., see the following code inside fea/mfea_proto_comm.cc, > ProtoComm::proto_socket_write(): > > if (dst.is_multicast()) { > set_default_multicast_vif(mfea_vif->vif_index()); > set_multicast_loop(true); > setloop = true; > } > > Hence, in your code you would have to explicitly ignore your own > control messages. E.g., see the following code inside pim/pim_vif.cc > PimVif::pim_process(): > > // Ignore my own PIM messages > if (pim_node().is_my_addr(src)) > return (XORP_ERROR); > > > If for whatever reason you cannot perform such check, then you can > try to comment-out the "set_multicast_loop(true)" statement inside > fea/mfea_proto_comm.cc. > > > Pavlin > > > > Thanks a lot. > > > > venkat > > > > ----- Original Message ----- > > From: Venketesan > > Date: Thursday, August 3, 2006 6:44 pm > > Subject: [Xorp-users] Looping back PIM messages > > > > > Hey all, > > > > > > I am writing a multicast tunneling protocol in linux redhat 9. > I > > > have > > > a program that > > > receives encapsulated PIm control messages on an interface > that > > > basically connects to a non multicast router. > > > The topology is the following > > > A---->0B1----->C > > > > > > A is a non xorp linux box. > > > B is a xorp linux box with my code running in it too. > > > C is a pure XORP linux box. > > > > > > I receive unicast encapsulated PIM control messages in B via > A. My > > > code > > > receves thise control messages and decapsulates and sends them > to > > > C. I > > > send these PIM-SM packets using a raw socket binded to IP > address > > > of > > > interface 1 in B. > > > > > > Now the issue is for some reason my program receves all the > PIM > > > control messages back that it was supposed to send out. Xorp > is > > > looping it back and not letting the packets go out of > interface1 > > > in B. > > > If i > > > stop xorp everything is fine and the packets are received at C. > > > Note that i am not listening over any raw socket just sending > PIM- > > > SM > > > packets using them. The way i receive is in the kernel i > intercept > > > PIM- > > > SM packets, make a copy of the same and pass it to my user > space > > > program using netlink sockets. > > > > > > Can anyone guide me on this issue, is it a expected behaviour > of > > > XORP > > > to loop back any PIM-SM control packet not orginated by itself. > > > I am using XORP 1.2 > > > regards, > > > Venkat > > > > > > _______________________________________________ > > > Xorp-users mailing list > > > Xorp-users at xorp.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From rodrigo at bolsistas.pop-rn.rnp.br Tue Aug 8 10:24:13 2006 From: rodrigo at bolsistas.pop-rn.rnp.br (rodrigo at bolsistas.pop-rn.rnp.br) Date: Tue, 8 Aug 2006 14:24:13 -0300 (BRT) Subject: [Xorp-users] Xorp Versions Message-ID: <32925.200.137.0.94.1155057853.squirrel@bolsistas.pop-rn.rnp.br> Hi, Recently, I received a Xorp v. 1.1 conf. file and I can't load it on the Xorp v. 1.2. Is there any significant change at the configuration form on version 1.2 from 1.1? I'm brazilian and I'm new user, so sorry my english mistakes. Thanks, Rodrigo Santiago From atanu at ICSI.Berkeley.EDU Tue Aug 8 10:55:31 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 08 Aug 2006 10:55:31 -0700 Subject: [Xorp-users] Xorp Versions In-Reply-To: Message from rodrigo@bolsistas.pop-rn.rnp.br of "Tue, 08 Aug 2006 14:24:13 -0300." <32925.200.137.0.94.1155057853.squirrel@bolsistas.pop-rn.rnp.br> Message-ID: <29749.1155059731@tigger.icir.org> Hi, All the changes between 1.1 and 1.2 are documented in the RELEASE_NOTES, by the way 1.3 is now available. Atanu. >>>>> "rodrigo" == rodrigo writes: rodrigo> Hi, Recently, I received a Xorp v. 1.1 conf. file and I rodrigo> can't load it on the Xorp v. 1.2. Is there any significant rodrigo> change at the configuration form on version 1.2 from 1.1? rodrigo> I'm brazilian and I'm new user, so sorry my english rodrigo> mistakes. rodrigo> Thanks, rodrigo> Rodrigo Santiago rodrigo> _______________________________________________ Xorp-users rodrigo> mailing list Xorp-users at xorp.org rodrigo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From rm at helica.org Tue Aug 8 13:45:54 2006 From: rm at helica.org (Robert M.) Date: Tue, 08 Aug 2006 22:45:54 +0200 Subject: [Xorp-users] iptv and multicast forwarding (newbie) In-Reply-To: <200608071949.k77JnZFY072302@possum.icir.org> References: <200608071949.k77JnZFY072302@possum.icir.org> Message-ID: <44D8F802.6030504@helica.org> [SNIP] > > Unfortunately, XORP doesn't implement (yet) the IGMP proxy > mechanism, and I am not aware of any open-source IGMP proxy > implementation. > > I found one at http://sourceforge.net/projects/igmpproxy . I'm testing it for a few days and it appears to work stable. BTW, looking at the source code I can see mrouted and smcroute joined together. There is another one at http://potiron.loria.fr/projects/madynes/internals/perso/lahmadi/igmpv3proxy . This one is evil and most importantly it doesn't work for me. For ipv6 (MLDv2) I found this one: http://unfix.org/projects/ecmh/ . [SNIP - config.boot template] After some extensive investigation on multicasts routing field, I can now understand your scepticism. Anyway, I'm going to try PIM-SM way and report my findings back to the list. Robert M. From steve.eckmann.ctr at mda.mil Wed Aug 9 10:37:09 2006 From: steve.eckmann.ctr at mda.mil (Eckmann, Steve CTR MDA/IC) Date: Wed, 9 Aug 2006 11:37:09 -0600 Subject: [Xorp-users] malformed PIM REGISTER messages? References: <200608072256.k77MujfF073976@possum.icir.org> Message-ID: <77BF8C8851DE034EA109FF82EE622A450147984A@USCEN-MAIL.uscentral.mda.mil> >> I am tunneling multicast between a Cisco router and a Linux/XORP >> router, using PIM-SM. If the RP is on the XORP router everything >> works. If the RP is on the Cisco router then mcast receivers >> attached to the XORP router can receive traffic sent from hosts on >> the Cisco side of the tunnel, but mcast receivers on the Cisco >> side do not receive mcast traffic sent by hosts on the XORP >> side. Ethereal running on an intermediate router or on the >> Linux/XORP router reports that the (GRE-wrapped) PIM REGISTER >> messages sent by XORP are "Malformed", and no encapsulated UDP >> datagram appears in the Ethereal display. The Cisco router appears >> to immediately send a PIM REGISTER_STOP instead of sending a >> JOIN_PRUNE when it receives one of these PIM REGISTER messages. So >> it looks like there might be something wrong with the PIM REGISTER >> messages. >> >> Any suggestions about what might cause this symptom? I'm running >> Fedora Core 4 Linux with XORP 1.2 (also tried the 1.3 Release >> Candidate; I see that official 1.3 became available >> yesterday...). > >Unfortunately, I don't have access to a Cisco router to try to >replicate your setup. >Can you run tcpdump instead and test whether you see similar >"malformed" message. If "yes", could you send me the content of that >malformed packet. >Also, what is the Linux distribution and kernel version you are >using? Fedora Core 4 with 2.6.11-1.1369_FC4 kernel. We got the same result without tunneling: we connected the Linux/XORP router directly to the Cisco router and still see the Cisco router responding with REGISTER_STOP to Linux REGISTER messages (that Ethereal considers malformed). I don't know how to tell whether tcpdump considers a packet malformed; it didn't complain about the REGISTER message in the attached file. Maybe somebody here is willing and able to do a sanity check on it; I depend on Ethereal for that... Thanks. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: pim-register.tcpdump Type: application/octet-stream Size: 106 bytes Desc: pim-register.tcpdump Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060809/a5824702/attachment.obj From pavlin at icir.org Wed Aug 9 11:45:22 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 Aug 2006 11:45:22 -0700 Subject: [Xorp-users] malformed PIM REGISTER messages? In-Reply-To: Message from "Eckmann, Steve CTR MDA/IC" of "Wed, 09 Aug 2006 11:37:09 MDT." <77BF8C8851DE034EA109FF82EE622A450147984A@USCEN-MAIL.uscentral.mda.mil> Message-ID: <200608091845.k79IjMEc086753@possum.icir.org> > Fedora Core 4 with 2.6.11-1.1369_FC4 kernel. > We got the same result without tunneling: we connected the > Linux/XORP router directly to the Cisco router and still see the > Cisco router responding with REGISTER_STOP to Linux REGISTER > messages (that Ethereal considers malformed). I don't know how to > tell whether tcpdump considers a packet malformed; it didn't > complain about the REGISTER message in the attached file. Maybe > somebody here is willing and able to do a sanity check on it; I > depend on Ethereal for that... I decoded the packet using tcpdump, and here is what it looks like: pavlin at xorp13[14] tcpdump -r pim-register.tcpdump -vvv -s 0 -x 10:10:18.931667 IP (tos 0x0, ttl 64, id 9, offset 0, flags [DF], proto: PIM (103), length: 52, options ( RA (148) len 4 )) 10.6.60.6 > 10.6.30.3: PIMv2, length: 28 Register N IP (tos 0x0, id 0, offset 0, flags [none], proto: PIM (103), length: 20) 10.6.60.10 > 239.16.2.2: 0x0000: 4600 0034 0009 4000 4067 3741 0a06 3c06 0x0010: 0a06 1e03 9404 0000 2100 9eff 4000 0000 0x0020: 4500 0014 0000 0000 0067 8361 0a06 3c0a 0x0030: ef10 0202 The interesting thing is that the inner (encapsulated) payload is a little bit odd: * It is a PIM packet, while usually it should be UDP. * Its packet's length is just 20 bytes (i.e., it contains only IP header). * That PIM packet was sent to multicast group 239.16.2.2, so it has nothing to do with the PIM protocol. * Its TTL is 0 so even if everything else didn't trigger the REGISTER_STOP by Cisco, it will be dropped anyway by the other side when decapsulated. Were you trying to test the multicast forwarding using PIM packets? FYI, the sender of that packet was 10.6.60.10. I would recommend to try with UDP packets and see whether the behavior will be different. Just don't forget to set the TTL of those UDP packets to be large enough, because the default multicast TTL is 1 :) Regards, Pavlin From steve.eckmann.ctr at mda.mil Wed Aug 9 13:10:52 2006 From: steve.eckmann.ctr at mda.mil (Eckmann, Steve CTR MDA/IC) Date: Wed, 9 Aug 2006 14:10:52 -0600 Subject: [Xorp-users] malformed PIM REGISTER messages? References: <200608091845.k79IjMEc086753@possum.icir.org> Message-ID: <77BF8C8851DE034EA109FF82EE622A450147984B@USCEN-MAIL.uscentral.mda.mil> >> Fedora Core 4 with 2.6.11-1.1369_FC4 kernel. >> We got the same result without tunneling: we connected the >> Linux/XORP router directly to the Cisco router and still see the >> Cisco router responding with REGISTER_STOP to Linux REGISTER >> messages (that Ethereal considers malformed). I don't know how to >> tell whether tcpdump considers a packet malformed; it didn't >> complain about the REGISTER message in the attached file. Maybe >> somebody here is willing and able to do a sanity check on it; I >> depend on Ethereal for that... > > I decoded the packet using tcpdump, and here is what it looks like: > > pavlin at xorp13[14] tcpdump -r pim-register.tcpdump -vvv -s 0 -x > 10:10:18.931667 IP (tos 0x0, ttl 64, id 9, offset 0, flags [DF], proto: PIM (103), length: 52, options ( RA (148) len 4 )) 10.6.60.6 > 10.6.30.3: PIMv2, length: 28 > Register N IP (tos 0x0, id 0, offset 0, flags [none], proto: PIM (103), length: 20) 10.6.60.10 > 239.16.2.2: > 0x0000: 4600 0034 0009 4000 4067 3741 0a06 3c06 > 0x0010: 0a06 1e03 9404 0000 2100 9eff 4000 0000 > 0x0020: 4500 0014 0000 0000 0067 8361 0a06 3c0a > 0x0030: ef10 0202 > > The interesting thing is that the inner (encapsulated) payload is a > little bit odd: > * It is a PIM packet, while usually it should be UDP. > * Its packet's length is just 20 bytes (i.e., it contains only IP > header). > * That PIM packet was sent to multicast group 239.16.2.2, so > it has nothing to do with the PIM protocol. > * Its TTL is 0 so even if everything else didn't trigger the > REGISTER_STOP by Cisco, it will be dropped anyway by the other > side when decapsulated. > > Were you trying to test the multicast forwarding using PIM packets? > FYI, the sender of that packet was 10.6.60.10. > > I would recommend to try with UDP packets and see whether the > behavior will be different. Just don't forget to set the TTL of > those UDP packets to be large enough, because the default multicast > TTL is 1 :) 10.6.60.10 is the host that is sending UDP multicast packets to group 239.16.2.2, so that part seems right. When I look at those packets on the host side of the XORP router I see TTL = 32. It is really weird that the PIM REGISTER packet I captured on the other side of the XORP router, which I thought should have one of the UDP packets encapsulated, apparently encapsulates another PIM packet. We might have fixed our problem by explicitly configuring the Cisco router to know that it is the RP. Isn't a PIM-SM router supposed to infer that it is an RP when it gets a JOIN or REGISTER message for a group? Anyway, I turned on debugging on the Cisco router and saw that it was refusing to be the RP when it got REGISTER messages. That behavior has stopped and the multicast traffic is flowing where it is supposed to. Thanks much for your troubleshooting suggestions, Pavlin. I think the problem turned out to be on the Cisco side, though I'm not sure that we identified the real problem, and I still don't understand the PIM traffic we see between the routers. Regards, Steve From vkaul at research.telcordia.com Wed Aug 9 14:07:16 2006 From: vkaul at research.telcordia.com (Vikram KAUL) Date: Wed, 9 Aug 2006 17:07:16 -0400 (Eastern Standard Time) Subject: [Xorp-users] MfeaVif flags_strings mod Message-ID: Folks I want to be able to add another attribute to the Mfea Vif from the config.boot file; but am not sure what is the best way to do so. I am not familiar with the templates, but I suppose a characteristic (enable/disable) has to be added in "mfea4.tp" and corresponding logic in the fea/mfea_vif.cc and .hh files Is there a help file/document that describes how to do so. Or can anyone provide any helpful pointers so I could ramp up quickly ? Thanks in advance Vikram From pavlin at icir.org Wed Aug 9 14:27:21 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 Aug 2006 14:27:21 -0700 Subject: [Xorp-users] malformed PIM REGISTER messages? In-Reply-To: Message from "Eckmann, Steve CTR MDA/IC" of "Wed, 09 Aug 2006 14:10:52 MDT." <77BF8C8851DE034EA109FF82EE622A450147984B@USCEN-MAIL.uscentral.mda.mil> Message-ID: <200608092127.k79LRLvm092539@possum.icir.org> > >> Fedora Core 4 with 2.6.11-1.1369_FC4 kernel. > >> We got the same result without tunneling: we connected the > >> Linux/XORP router directly to the Cisco router and still see the > >> Cisco router responding with REGISTER_STOP to Linux REGISTER > >> messages (that Ethereal considers malformed). I don't know how to > >> tell whether tcpdump considers a packet malformed; it didn't > >> complain about the REGISTER message in the attached file. Maybe > >> somebody here is willing and able to do a sanity check on it; I > >> depend on Ethereal for that... > > > > I decoded the packet using tcpdump, and here is what it looks like: > > > > pavlin at xorp13[14] tcpdump -r pim-register.tcpdump -vvv -s 0 -x > > 10:10:18.931667 IP (tos 0x0, ttl 64, id 9, offset 0, flags [DF], proto: PIM (103), length: 52, options ( RA (148) len 4 )) 10.6.60.6 > 10.6.30.3: PIMv2, length: 28 > > Register N IP (tos 0x0, id 0, offset 0, flags [none], proto: PIM (103), length: 20) 10.6.60.10 > 239.16.2.2: > > 0x0000: 4600 0034 0009 4000 4067 3741 0a06 3c06 > > 0x0010: 0a06 1e03 9404 0000 2100 9eff 4000 0000 > > 0x0020: 4500 0014 0000 0000 0067 8361 0a06 3c0a > > 0x0030: ef10 0202 > > > > The interesting thing is that the inner (encapsulated) payload is a > > little bit odd: > > * It is a PIM packet, while usually it should be UDP. > > * Its packet's length is just 20 bytes (i.e., it contains only IP > > header). > > * That PIM packet was sent to multicast group 239.16.2.2, so > > it has nothing to do with the PIM protocol. > > * Its TTL is 0 so even if everything else didn't trigger the > > REGISTER_STOP by Cisco, it will be dropped anyway by the other > > side when decapsulated. Sorry, I take the above back. This particular packet is the PIM Null Register, which should look like what you see. After the DR (XORP) receives the PIM Register Stop from the RP, it will periodically send such PIM Null Registers. You would see the normal PIM Registers only on startup before you receive the PIM Register Stop from the RP (or only if the RP doesn't respond to the PIM Null Register with PIM Register Stop). > > Were you trying to test the multicast forwarding using PIM packets? > > FYI, the sender of that packet was 10.6.60.10. > > > > I would recommend to try with UDP packets and see whether the > > behavior will be different. Just don't forget to set the TTL of > > those UDP packets to be large enough, because the default multicast > > TTL is 1 :) > > 10.6.60.10 is the host that is sending UDP multicast packets to group > 239.16.2.2, so that part seems right. When I look at those packets > on the host side of the XORP router I see TTL = 32. It is really weird > that the PIM REGISTER packet I captured on the other side of the XORP > router, which I thought should have one of the UDP packets encapsulated, > apparently encapsulates another PIM packet. This packet is normal (see my correction above). > We might have fixed our problem by explicitly configuring the Cisco > router to know that it is the RP. Isn't a PIM-SM router supposed to > infer that it is an RP when it gets a JOIN or REGISTER message for > a group? Anyway, I turned on debugging on the Cisco router and saw that > it was refusing to be the RP when it got REGISTER messages. That > behavior has stopped and the multicast traffic is flowing where it > is supposed to. > > Thanks much for your troubleshooting suggestions, Pavlin. I think > the problem turned out to be on the Cisco side, though I'm not sure > that we identified the real problem, and I still don't understand > the PIM traffic we see between the routers. >From what you say above it seems that everything is in order and now the multicast traffic is forwarded without any issues. Sorry about the false alarm for the PIM Register packet. I should have analyzed it based on what I see rather than based on what I expected to see :) Regards, Pavlin From pavlin at icir.org Wed Aug 9 14:45:13 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 Aug 2006 14:45:13 -0700 Subject: [Xorp-users] MfeaVif flags_strings mod In-Reply-To: Message from Vikram KAUL of "Wed, 09 Aug 2006 17:07:16 EDT." Message-ID: <200608092145.k79LjDfg092729@possum.icir.org> > I want to be able to add another attribute to the Mfea Vif from the > config.boot file; but am not sure what is the best way to do so. I am not > familiar with the templates, but I suppose a characteristic > (enable/disable) has to be added in "mfea4.tp" and corresponding logic in > the fea/mfea_vif.cc and .hh files > > Is there a help file/document that describes how to do so. Or can anyone > provide any helpful pointers so I could ramp up quickly ? This is going to be a bit tricky, because you would have to modify several things: 1. Modify the etc/templates/mfea4.tp template to include your flag and the appropriate XRL to set it. Use the "disable" flag as a reference (or implementation for the deprecated "enable" flag). 2. Implement that XRL as part of the MFEA XRL interface: xrl/interfaces/mfea.xif Use the "enable_vif" XRL as a reference. 3. Implement the mechanism inside the MFEA to set the flag per vif. Use the MfeaNode::enable_vif() implementation as a reference. However, in addition you would need to modify Mfea::set_config_vif_flags() to include support for your new flag, and then you need to call that method to set your flag when modified. Finally, the set_config_vif_flags() call should be followed by a call to set_config_all_vifs_done(). 4. The mfea_client/0.1/set_vif_flags XRL should be modified to include your flag. 5. The receiving side of mfea_client/0.1/set_vif_flags (IGMP/MLD and PIM-SM) should process that flag as any of the other vif flags, and update the local vif copy. If you need that flag only in the MFEA and you don't need it propagated to the IGMP/MLD or PIM modules, then you don't need to implement (4) and (5). Hope that helps, Pavlin From ahthamrin at gmail.com Mon Aug 14 03:46:19 2006 From: ahthamrin at gmail.com (A.H.T) Date: Mon, 14 Aug 2006 19:46:19 +0900 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop Message-ID: <4250f3610608140346h755957d2n35ed3d1dcff0682e@mail.gmail.com> Hi, I am using XORP 1.3-Release for PIM-SMv6 and Zebra 0.95 for unicast routing on FreeBSD 6.1. The situations are: 1. xorpsh sometimes issues recursive malloc calls, causing segmentation fault. 2. XORP doesn't update its nexthop vif on multicast routing table If Zebra updates a routing entry. show route table ipv6 multicast fib2mrib shows that the nexthop vif is not changed even though the nexthop address is. I am not sure whether this problem is intermittent or not. 3. I am wondering if this is a bug or not. I set the switch-to-spt-threshold to a non-0 value, and my PIM RP never initiates a Register-Stop, i.e.: a. The RP doesn't issue a Register-Stop when it receives PIM Register packets for multicast group without any Join state. b. The RP doesn't issue a Register-Stop for PIM Register packets when there's a Join state but no oif (i.e. the last-hop router switched to SPT and the RP is not a router in the SPT). c. The RP only issues a Register-Stop if it receives a Join(S,G) message. If it is a bug, I guess the below snippets are enough to make RP issues a Register-Stop. %rcsdiff -u pim_proto_register.cc =================================================================== RCS file: RCS/pim_proto_register.cc,v retrieving revision 1.1 diff -u -r1.1 pim_proto_register.cc --- pim_proto_register.cc 2006/08/14 09:21:51 1.1 +++ pim_proto_register.cc 2006/08/14 10:27:40 @@ -302,8 +302,7 @@ // messages reaches the configured threshold. // if (is_sptbit_set - || (pim_mre->is_switch_to_spt_desired_sg(0, 0) - && pim_mre->inherited_olist_sg().none())) { + || pim_mre->inherited_olist_sg().none()) { // // "send Register-Stop(S,G) to outer.src" // %rcsdiff -u pim_mre_data.cc =================================================================== RCS file: RCS/pim_mre_data.cc,v retrieving revision 1.1 diff -u -r1.1 pim_mre_data.cc --- pim_mre_data.cc 2006/08/14 09:20:51 1.1 +++ pim_mre_data.cc 2006/08/14 09:21:42 @@ -101,6 +101,11 @@ if (! (is_wc() || is_sg() || is_sg_rpt())) return (false); + // + // RP SPT switch + // + if (i_am_rp()) + return (true); mifs = pim_include_wc(); if (pim_mre_sg != NULL) { mifs &= ~pim_mre_sg->pim_exclude_sg(); regards, -- From pavlin at icir.org Mon Aug 14 11:04:15 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 14 Aug 2006 11:04:15 -0700 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: Message from "A.H.T" of "Mon, 14 Aug 2006 19:46:19 +0900." <4250f3610608140346h755957d2n35ed3d1dcff0682e@mail.gmail.com> Message-ID: <200608141804.k7EI4F5V061894@possum.icir.org> > I am using XORP 1.3-Release for PIM-SMv6 and Zebra 0.95 for unicast > routing on FreeBSD 6.1. > The situations are: > 1. xorpsh sometimes issues recursive malloc calls, causing segmentation fault. Is the problem reproducible? If "yes", can you provide detailed instructions how to trigger it. If "no", can you send a backtrace of the coredump. > 2. XORP doesn't update its nexthop vif on multicast routing table If > Zebra updates a routing entry. > show route table ipv6 multicast fib2mrib shows that the nexthop > vif is not changed even though the nexthop address is. > I am not sure whether this problem is intermittent or not. Can you trigger the same problem by using userland commands like "route delete" and "route add". If "yes", could you provide the sequence of those commands. > 3. I am wondering if this is a bug or not. I set the > switch-to-spt-threshold to a non-0 value, and my PIM RP never > initiates a Register-Stop, i.e.: > a. The RP doesn't issue a Register-Stop when it receives PIM > Register packets for multicast group without any Join state. > b. The RP doesn't issue a Register-Stop for PIM Register packets > when there's a Join state but no oif (i.e. the last-hop router > switched to SPT and the RP is not a router in the SPT). > c. The RP only issues a Register-Stop if it receives a Join(S,G) message. Regarding (a) and (b): In earlier versions of the PIM-SM spec, if the RP didn't have any Join state (or if the Join state was with NULL oif set), the Register-Stop was generated for the first PIM Register packet. Later the spec was modified such that the Register-Stop is generated only if the PIM Registers bandwidth is above the "switch-to-spt" bandwidth threshold. Hence, if you increase the sender's bandwidth, eventually the RP would generate a Register-Stop. Note that the FreeBSD IPv6 multicast forwarding support in the kernel doesn't support the multicast bandwidth upcall mechanism, so it might take a while until the userland mechanism (periodic polling) detects the high bandwidth dataflow. The "show mfea6 dataflow" xorpsh command can be used as a guide to tell you when the bandwidth threshold has been reached. Regarding (c): In this scenario eventually the data will start arriving on the shortest-path, hence the RP will immediately send Register-Stop for any PIM Register packets. Regards, Pavlin > If it is a bug, I guess the below snippets are enough to make RP > issues a Register-Stop. > > %rcsdiff -u pim_proto_register.cc > =================================================================== > RCS file: RCS/pim_proto_register.cc,v > retrieving revision 1.1 > diff -u -r1.1 pim_proto_register.cc > --- pim_proto_register.cc 2006/08/14 09:21:51 1.1 > +++ pim_proto_register.cc 2006/08/14 10:27:40 > @@ -302,8 +302,7 @@ > // messages reaches the configured threshold. > // > if (is_sptbit_set > - || (pim_mre->is_switch_to_spt_desired_sg(0, 0) > - && pim_mre->inherited_olist_sg().none())) { > + || pim_mre->inherited_olist_sg().none()) { > // > // "send Register-Stop(S,G) to outer.src" > // > %rcsdiff -u pim_mre_data.cc > =================================================================== > RCS file: RCS/pim_mre_data.cc,v > retrieving revision 1.1 > diff -u -r1.1 pim_mre_data.cc > --- pim_mre_data.cc 2006/08/14 09:20:51 1.1 > +++ pim_mre_data.cc 2006/08/14 09:21:42 > @@ -101,6 +101,11 @@ > if (! (is_wc() || is_sg() || is_sg_rpt())) > return (false); > > + // > + // RP SPT switch > + // > + if (i_am_rp()) > + return (true); > mifs = pim_include_wc(); > if (pim_mre_sg != NULL) { > mifs &= ~pim_mre_sg->pim_exclude_sg(); > > > regards, > > -- > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From meyett_donald at bah.com Tue Aug 15 11:21:31 2006 From: meyett_donald at bah.com (Meyett Donald) Date: Tue, 15 Aug 2006 14:21:31 -0400 Subject: [Xorp-users] What IDE to use for development? Message-ID: When I load xorp-1.2 or xorp-1.3 source code into kdevelop or anjuta it kills the IDE. Is this a known problem? Is there a recommended Linux-based IDE from which to develop? I've duplicated this across multiple versions of Linux (RHEL ES4, RHEL WS, FC4 and FC5) as well as multiple versions of kdevelop (3.3.1, 3.3.3) and anjuta (1.2.4 and 2.0.2). I'm not sure if this is an issue with the xorp code or a much larger (possibly) kernel related issue. Thanks in advance. Don Meyett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060815/644bcbc6/attachment.html From atanu at ICSI.Berkeley.EDU Tue Aug 15 11:28:23 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 15 Aug 2006 11:28:23 -0700 Subject: [Xorp-users] What IDE to use for development? In-Reply-To: Message from "Meyett Donald" of "Tue, 15 Aug 2006 14:21:31 EDT." Message-ID: <43912.1155666503@tigger.icir.org> Hi, None of the developers use an IDE, you are probably the first to have attempted it. If you manage to get one working please keep us informed. Atanu. >>>>> "Meyett" == Meyett Donald writes: Meyett> When I load xorp-1.2 or xorp-1.3 source code into Meyett> kdevelop or anjuta it kills the IDE. Is this a known Meyett> problem? Is there a recommended Linux-based IDE from which Meyett> to develop? I've duplicated this across multiple versions Meyett> of Linux (RHEL ES4, RHEL WS, FC4 and FC5) as well as Meyett> multiple versions of kdevelop (3.3.1, 3.3.3) and anjuta Meyett> (1.2.4 and 2.0.2). I'm not sure if this is an issue with Meyett> the xorp code or a much larger (possibly) kernel related Meyett> issue. Meyett> Thanks in advance. Meyett> Don Meyett Meyett> _______________________________________________ Xorp-users Meyett> mailing list Xorp-users at xorp.org Meyett> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From aidan at wires3.net Wed Aug 16 00:17:49 2006 From: aidan at wires3.net (Aidan Walton) Date: Wed, 16 Aug 2006 08:17:49 +0100 Subject: [Xorp-users] SNMP & QoS Message-ID: <1155712669.30471.24.camel@localhost> Hi Folks, I have a couple of questions if anyone could spare the time I would love to know the answers: 1. I recently watched CVS commits of round_robin.cc, round_robin.hh and was wondering how this QoS capability gets enabled in the configuration and if it is now active if I compile the latest CVS snapshot. (I assume this is QoS and not a round robin algorithm for some other function rather than traffic management) 2. Has anyone written any more MIBs, I got SNMP working recently but the most useful MIB, to me, does not seem to be available. A simple interface monitoring MIB, traffic stats, errors, drops etc. Is this related to the underlying kernel forwarding function in use? Does this complicate the implementation? Or maybe I missed something? Any idea, thanks for 1.3! Great work. Aidan From M.Handley at cs.ucl.ac.uk Wed Aug 16 01:46:20 2006 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Wed, 16 Aug 2006 09:46:20 +0100 Subject: [Xorp-users] SNMP & QoS In-Reply-To: <1155712669.30471.24.camel@localhost> References: <1155712669.30471.24.camel@localhost> Message-ID: <84a612dd0608160146u764ab515m55ff6f72a92a31d@mail.gmail.com> On 8/16/06, Aidan Walton wrote: > 1. I recently watched CVS commits of round_robin.cc, round_robin.hh and > was wondering how this QoS capability gets enabled in the configuration > and if it is now active if I compile the latest CVS snapshot. (I assume > this is QoS and not a round robin algorithm for some other function > rather than traffic management) round_robin is not a packet scheduler, but part of the new XORP internal task scheduler. Previously within each XORP process we had timers and selectors (sockets), and background tasks used zero-second timers. Under high levels of load, we could get backlogged and not perform essential timers or other functions until it was too late. The new task scheduler has priority levels for timers, sockets, and background tasks, and then for tasks within each priority level we do weighted round robin scheduling. This allows us to prioritise important timers or sockets, and to schedule some tasks more than others without starving any (as would be the case with pure priorities). The aim is that this should make XORP (especially XORP BGP) more robust under overload conditions. But it's early days yet - I only wrote the new scheduler last week - and no doubt we'll have to do some tuning to get this right. So, sorry, not QoS. That would be part of the forwarding path, and XORP (so far) focusses on the control plane leaving forwarding to the kernel. - Mark From aidan at wires3.net Wed Aug 16 06:07:07 2006 From: aidan at wires3.net (Aidan Walton) Date: Wed, 16 Aug 2006 14:07:07 +0100 Subject: [Xorp-users] SNMP & QoS In-Reply-To: <84a612dd0608160146u764ab515m55ff6f72a92a31d@mail.gmail.com> References: <1155712669.30471.24.camel@localhost> <84a612dd0608160146u764ab515m55ff6f72a92a31d@mail.gmail.com> Message-ID: <1155733628.30471.45.camel@localhost> Thanks Mark, Well it just goes to show, never assume anything. However it seems I wasn't a million miles off the mark. I imagine I can use other packet scheduling techniques that are workable with my kernel independently of the control plane, so for traffic management I still have options. Back to the work you just did though. Can I work out easily what tasks you consider are critical in the process schedule by looking at this code. I have memories of ARP on a Ethernet/MAN segment being a killer of control plane code if not rate limited. Is this the sort of thing that can now be achieved? Also does XORP currently have any control over how protocol traffic gets inserted onto outgoing interfaces? As I remember another historical problem was neighbour sessions dropping (BGP & IGP) if control plane traffic could not be prioritised during heavy data plane loads. I (once again) assume the FEA has some control of how control traffic gets inserted into the kernel forwarding plane, but I was under the impression that the kernel forwarding plane was independent of XORP and its abstraction layers, so how do we prioritise control plane traffic as it traverses the kernel forwarding plane? I suspect my answer is in my first paragraph, is this correct? Cheers Aidan On Wed, 2006-08-16 at 09:46 +0100, Mark Handley wrote: > On 8/16/06, Aidan Walton wrote: > > 1. I recently watched CVS commits of round_robin.cc, round_robin.hh and > > was wondering how this QoS capability gets enabled in the configuration > > and if it is now active if I compile the latest CVS snapshot. (I assume > > this is QoS and not a round robin algorithm for some other function > > rather than traffic management) > > round_robin is not a packet scheduler, but part of the new XORP > internal task scheduler. > > Previously within each XORP process we had timers and selectors > (sockets), and background tasks used zero-second timers. Under high > levels of load, we could get backlogged and not perform essential > timers or other functions until it was too late. > > The new task scheduler has priority levels for timers, sockets, and > background tasks, and then for tasks within each priority level we do > weighted round robin scheduling. This allows us to prioritise > important timers or sockets, and to schedule some tasks more than > others without starving any (as would be the case with pure > priorities). > > The aim is that this should make XORP (especially XORP BGP) more > robust under overload conditions. But it's early days yet - I only > wrote the new scheduler last week - and no doubt we'll have to do some > tuning to get this right. > > So, sorry, not QoS. That would be part of the forwarding path, and > XORP (so far) focusses on the control plane leaving forwarding to the > kernel. > > - Mark From venkthi1 at iit.edu Wed Aug 16 15:47:12 2006 From: venkthi1 at iit.edu (Venketesan) Date: Wed, 16 Aug 2006 15:47:12 -0700 Subject: [Xorp-users] SSM applications Message-ID: <19742b19542d.19542d19742b@iit.edu> Hi all, I want to run some experimments over the SSM functionality in XORP. Can anyone point me to an multicast application that supports SSM. A video application like VIC would be perfect, but i don't know if we have VIC (SSM version) available for windows. My host machines are on XP. thanks, Venkat From pavlin at icir.org Wed Aug 16 17:06:36 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 16 Aug 2006 17:06:36 -0700 Subject: [Xorp-users] SSM applications In-Reply-To: Message from Venketesan of "Wed, 16 Aug 2006 15:47:12 PDT." <19742b19542d.19542d19742b@iit.edu> Message-ID: <200608170006.k7H06apX024996@possum.icir.org> > I want to run some experimments over the SSM functionality in XORP. > Can anyone point me to an multicast application that supports SSM. > A video application like VIC would be perfect, but i don't know if we > have VIC (SSM version) available for windows. My host machines are on > XP. One tool you can try is ssmping, which should work on Windows: http://www.venaas.no/multicast/ssmping/ Sorry, don't have any pointers about SSM-enabled VIC for Windows XP. Pavlin From tsousa at netcabo.pt Wed Aug 16 17:18:01 2006 From: tsousa at netcabo.pt (Tiago Sousa) Date: Thu, 17 Aug 2006 01:18:01 +0100 Subject: [Xorp-users] SSM applications In-Reply-To: <200608170006.k7H06apX024996@possum.icir.org> Message-ID: <005001c6c192$9a79fe30$6401a8c0@Undercover> Hello, Here you are: http://www-rp.lip6.fr/~kabassan/ Tiago -----Mensagem original----- De: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] Em nome de Pavlin Radoslavov Enviada: quinta-feira, 17 de Agosto de 2006 1:07 Para: Venketesan Cc: xorp-users at xorp.org Assunto: Re: [Xorp-users] SSM applications > I want to run some experimments over the SSM functionality in XORP. > Can anyone point me to an multicast application that supports SSM. > A video application like VIC would be perfect, but i don't know if we > have VIC (SSM version) available for windows. My host machines are on > XP. One tool you can try is ssmping, which should work on Windows: http://www.venaas.no/multicast/ssmping/ Sorry, don't have any pointers about SSM-enabled VIC for Windows XP. Pavlin _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From M.Handley at cs.ucl.ac.uk Thu Aug 17 03:50:54 2006 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Thu, 17 Aug 2006 11:50:54 +0100 Subject: [Xorp-users] Fwd: Re: SSM applications In-Reply-To: References: <19742b19542d.19542d19742b@iit.edu> <84a612dd0608170155j6e8aab25i5c2b31093368e084@mail.gmail.com> Message-ID: <84a612dd0608170350u483dec2bq5bdcc96e5ab49c00@mail.gmail.com> Venkat, I asked Piers O'Hanlon about SSM apps. Here's his reply. - Mark ---------- Forwarded message ---------- From: Piers O'Hanlon Date: Aug 17, 2006 11:23 AM Subject: Re: [Xorp-users] SSM applications To: Mark Handley Hi Mark, Videolan.org supports SSM for Windows: VLC syntax for SSM streams is udp://server_ip at multicast_group:port For BSD there's DVTS and MIM: http://www-sop.inria.fr/planete/Hitoshi.Asaeda/dvts/ http://videolab.uoregon.edu/mim/ I will also modfiy vic to do SSM on WinXP shortly. Piers. On 8/17/06, Mark Handley wrote: > Is there an SSM video tool available for Windows? > > - Mark > > ---------- Forwarded message ---------- > From: Venketesan > Date: Aug 16, 2006 11:47 PM > Subject: [Xorp-users] SSM applications > To: xorp-users at xorp.org > > > Hi all, > I want to run some experimments over the SSM functionality in XORP. > Can anyone point me to an multicast application that supports SSM. > A video application like VIC would be perfect, but i don't know if we > have VIC (SSM version) available for windows. My host machines are on > XP. > > thanks, > Venkat > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From asaeda at sfc.wide.ad.jp Thu Aug 17 07:32:09 2006 From: asaeda at sfc.wide.ad.jp (Hitoshi Asaeda) Date: Thu, 17 Aug 2006 23:32:09 +0900 (JST) Subject: [Xorp-users] Fwd: Re: SSM applications In-Reply-To: <84a612dd0608170350u483dec2bq5bdcc96e5ab49c00@mail.gmail.com> References: <84a612dd0608170155j6e8aab25i5c2b31093368e084@mail.gmail.com> <84a612dd0608170350u483dec2bq5bdcc96e5ab49c00@mail.gmail.com> Message-ID: <20060817.233209.97299006.asaeda@sfc.wide.ad.jp> > For BSD there's DVTS and MIM: > http://www-sop.inria.fr/planete/Hitoshi.Asaeda/dvts/ DVTS (http://www.sfc.wide.ad.jp/DVTS) supports Linux/BSD/MacOSX/WinXP. The latest Linux/BSD version (aka dvts-1.0e) needs above patch to enable SSM. (I expect WIDE will release the new SSM-capable version within a short period.) Regarding XP's DVTS, the latest version already supports SSM, I heard. -- Hitoshi Asaeda From ahthamrin at gmail.com Thu Aug 17 10:24:37 2006 From: ahthamrin at gmail.com (A.H.T) Date: Fri, 18 Aug 2006 02:24:37 +0900 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: <200608141804.k7EI4F5V061894@possum.icir.org> References: <4250f3610608140346h755957d2n35ed3d1dcff0682e@mail.gmail.com> <200608141804.k7EI4F5V061894@possum.icir.org> Message-ID: <4250f3610608171024q47d3daf5rf5b6a1af51d6c7c0@mail.gmail.com> On 8/15/06, Pavlin Radoslavov wrote: > > I am using XORP 1.3-Release for PIM-SMv6 and Zebra 0.95 for unicast > > routing on FreeBSD 6.1. > > The situations are: > > 1. xorpsh sometimes issues recursive malloc calls, causing segmentation fault. > > Is the problem reproducible? > If "yes", can you provide detailed instructions how to trigger it. > If "no", can you send a backtrace of the coredump. It sometimes happened after I gave "show pim6 join" or "show pim6 mrib" the XORP was not compiled with -ggdb on, so the backtrace after the "show pim6 join" is #0 0x284d4363 in kill () from /lib/libc.so.6 (gdb) bt #0 0x284d4363 in kill () from /lib/libc.so.6 #1 0x284d4300 in raise () from /lib/libc.so.6 #2 0x284d3014 in abort () from /lib/libc.so.6 #3 0x284794d3 in _UTF8_init () from /lib/libc.so.6 #4 0xbfbfed98 in ?? () #5 0x284da4c9 in sys_nsig () from /lib/libc.so.6 #6 0x284da3d7 in sys_nsig () from /lib/libc.so.6 #7 0x284da49b in sys_nsig () from /lib/libc.so.6 #8 0x00000000 in ?? () #9 0x284e4508 in ?? () from /lib/libc.so.6 #10 0xbfbec2c8 in ?? () #11 0x28479501 in _UTF8_init () from /lib/libc.so.6 #12 0x284e4508 in ?? () from /lib/libc.so.6 #13 0x08230564 in vtable for __cxxabiv1::__class_type_info () #14 0xbfbec378 in ?? () #15 0x2847a588 in _UTF8_init () from /lib/libc.so.6 #16 0x00000020 in ?? () Previous frame inner to this frame (corrupt stack?) > > > 2. XORP doesn't update its nexthop vif on multicast routing table If > > Zebra updates a routing entry. > > show route table ipv6 multicast fib2mrib shows that the nexthop > > vif is not changed even though the nexthop address is. > > I am not sure whether this problem is intermittent or not. > > Can you trigger the same problem by using userland commands like > "route delete" and "route add". If "yes", could you provide the > sequence of those commands. Here's the snippet of the ndp command on my router fe80::2e0:81ff:fe20:afc2%fxp0 0:e0:81:20:af:c2 fxp0 16h26m32s S R fe80::207:e9ff:fe05:ba6f%fxp1 0:7:e9:5:ba:6f fxp1 17s R R a. after route -n add -inet6 A:B:C:D::/64 fe80::2e0:81ff:fe20:afc2%fxp0 show pim6 mrib shows A:B:C:D::/64 fe80::2e0:81ff:fe20:afc2 fxp0 0 254 65535 b. after route -n change -inet6 A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f%fxp1 show pim6 mrib shows A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f fxp0 0 254 65535 c. deleting the A:B:C:D::/64 and then route -n add -inet6 A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f%fxp1 gives the same result show pim6 mrib shows A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f fxp0 0 254 65535 Thank you for your explanation on point 3. regards -- From meyett_donald at bah.com Thu Aug 17 10:25:56 2006 From: meyett_donald at bah.com (Meyett Donald) Date: Thu, 17 Aug 2006 13:25:56 -0400 Subject: [Xorp-users] What IDE to use for development? Message-ID: It appears that the culprit is xorp-1.x/Makefile.am. Removing this file results in the IDE loading the project correctly but I imagine there is a loss of functionality, i.e.. being able to automake from the GUI. I haven't narrowed down the exact cause of the problem within the makefile but I will keep you posted in the event I do. Thanks! Don Meyett Booz, Allen, Hamilton Email - meyett_donald at bah.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060817/956df405/attachment.html From pavlin at icir.org Thu Aug 17 15:55:33 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 17 Aug 2006 15:55:33 -0700 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: Message from "A.H.T" of "Fri, 18 Aug 2006 02:24:37 +0900." <4250f3610608171024q47d3daf5rf5b6a1af51d6c7c0@mail.gmail.com> Message-ID: <200608172255.k7HMtXMJ045213@possum.icir.org> > On 8/15/06, Pavlin Radoslavov wrote: > > > I am using XORP 1.3-Release for PIM-SMv6 and Zebra 0.95 for unicast > > > routing on FreeBSD 6.1. > > > The situations are: > > > 1. xorpsh sometimes issues recursive malloc calls, causing segmentation fault. > > > > Is the problem reproducible? > > If "yes", can you provide detailed instructions how to trigger it. > > If "no", can you send a backtrace of the coredump. > It sometimes happened after I gave "show pim6 join" or "show pim6 mrib" > > the XORP was not compiled with -ggdb on, so the backtrace after the > "show pim6 join" is > #0 0x284d4363 in kill () from /lib/libc.so.6 > (gdb) bt > #0 0x284d4363 in kill () from /lib/libc.so.6 > #1 0x284d4300 in raise () from /lib/libc.so.6 > #2 0x284d3014 in abort () from /lib/libc.so.6 > #3 0x284794d3 in _UTF8_init () from /lib/libc.so.6 > #4 0xbfbfed98 in ?? () > #5 0x284da4c9 in sys_nsig () from /lib/libc.so.6 > #6 0x284da3d7 in sys_nsig () from /lib/libc.so.6 > #7 0x284da49b in sys_nsig () from /lib/libc.so.6 > #8 0x00000000 in ?? () > #9 0x284e4508 in ?? () from /lib/libc.so.6 > #10 0xbfbec2c8 in ?? () > #11 0x28479501 in _UTF8_init () from /lib/libc.so.6 > #12 0x284e4508 in ?? () from /lib/libc.so.6 > #13 0x08230564 in vtable for __cxxabiv1::__class_type_info () > #14 0xbfbec378 in ?? () > #15 0x2847a588 in _UTF8_init () from /lib/libc.so.6 > #16 0x00000020 in ?? () > Previous frame inner to this frame (corrupt stack?) Thank you for the update. It is not sufficient to point the source of the failure, but seems consistent with another backtrace I got this morning from Mark Handley. Anyway, I just committed some code that hopefully will print some debug info if this happens again: Revision Changes Path 1.27 +13 -4; commitid: 14b3f44e4f1357ea6; xorp/libxorp/run_command.cc Please update this file (only) with the changes and next time it happens please send me printed messages. > > > 2. XORP doesn't update its nexthop vif on multicast routing table If > > > Zebra updates a routing entry. > > > show route table ipv6 multicast fib2mrib shows that the nexthop > > > vif is not changed even though the nexthop address is. > > > I am not sure whether this problem is intermittent or not. > > > > Can you trigger the same problem by using userland commands like > > "route delete" and "route add". If "yes", could you provide the > > sequence of those commands. > > Here's the snippet of the ndp command on my router > fe80::2e0:81ff:fe20:afc2%fxp0 0:e0:81:20:af:c2 fxp0 16h26m32s S R > fe80::207:e9ff:fe05:ba6f%fxp1 0:7:e9:5:ba:6f fxp1 17s R R > > a. after > route -n add -inet6 A:B:C:D::/64 fe80::2e0:81ff:fe20:afc2%fxp0 > > show pim6 mrib shows > A:B:C:D::/64 fe80::2e0:81ff:fe20:afc2 fxp0 0 254 65535 > > b. after > route -n change -inet6 A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f%fxp1 > show pim6 mrib shows > A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f fxp0 0 254 65535 > > c. deleting the A:B:C:D::/64 and then > route -n add -inet6 A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f%fxp1 > gives the same result > > show pim6 mrib shows > A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f fxp0 0 254 65535 Thank you for the info. I will look into that. Pavlin From pavlin at icir.org Thu Aug 17 22:35:02 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 17 Aug 2006 22:35:02 -0700 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: Message from Pavlin Radoslavov of "Thu, 17 Aug 2006 15:55:33 PDT." <200608172255.k7HMtXMJ045213@possum.icir.org> Message-ID: <200608180535.k7I5Z2w5071333@possum.icir.org> > > > > 2. XORP doesn't update its nexthop vif on multicast routing table If > > > > Zebra updates a routing entry. > > > > show route table ipv6 multicast fib2mrib shows that the nexthop > > > > vif is not changed even though the nexthop address is. > > > > I am not sure whether this problem is intermittent or not. > > > > > > Can you trigger the same problem by using userland commands like > > > "route delete" and "route add". If "yes", could you provide the > > > sequence of those commands. > > > > Here's the snippet of the ndp command on my router > > fe80::2e0:81ff:fe20:afc2%fxp0 0:e0:81:20:af:c2 fxp0 16h26m32s S R > > fe80::207:e9ff:fe05:ba6f%fxp1 0:7:e9:5:ba:6f fxp1 17s R R > > > > a. after > > route -n add -inet6 A:B:C:D::/64 fe80::2e0:81ff:fe20:afc2%fxp0 > > > > show pim6 mrib shows > > A:B:C:D::/64 fe80::2e0:81ff:fe20:afc2 fxp0 0 254 65535 > > > > b. after > > route -n change -inet6 A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f%fxp1 > > show pim6 mrib shows > > A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f fxp0 0 254 65535 > > > > c. deleting the A:B:C:D::/64 and then > > route -n add -inet6 A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f%fxp1 > > gives the same result > > > > show pim6 mrib shows > > A:B:C:D::/64 fe80::207:e9ff:fe05:ba6f fxp0 0 254 65535 > > Thank you for the info. I will look into that. I think I found the bug. I believe it was triggered in certain cases. E.g., one of the cases was when the next-hop is an IPv6 link-local address that belongs to the router itself. Now it should be fixed in CVS: Revision Changes Path 1.15 +116 -1; commitid: 156da44e53f497ea6; xorp/libfeaclient/ifmgr_atoms.cc 1.24 +46 -1; commitid: 156da44e53f497ea6; xorp/libfeaclient/ifmgr_atoms.hh 1.31 +11 -5; commitid: 1595844e54db77ea6; xorp/fib2mrib/fib2mrib_node.cc Please let me know if you still have the problem. Thanks, Pavlin From ahthamrin at gmail.com Mon Aug 21 00:01:30 2006 From: ahthamrin at gmail.com (A.H.T) Date: Mon, 21 Aug 2006 16:01:30 +0900 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: <200608180535.k7I5Z2w5071333@possum.icir.org> References: <200608172255.k7HMtXMJ045213@possum.icir.org> <200608180535.k7I5Z2w5071333@possum.icir.org> Message-ID: <4250f3610608210001n5e5c5275v84fcdc6016f495d5@mail.gmail.com> Hi Pavlin, > Now it should be fixed in CVS: > > Revision Changes Path > 1.15 +116 -1; commitid: 156da44e53f497ea6; xorp/libfeaclient/ifmgr_atoms.cc > 1.24 +46 -1; commitid: 156da44e53f497ea6; xorp/libfeaclient/ifmgr_atoms.hh > 1.31 +11 -5; commitid: 1595844e54db77ea6; xorp/fib2mrib/fib2mrib_node.cc > > Please let me know if you still have the problem. > Thank you for the patch. I also saw that you fixed the nexthop interface problem in fea/routing_socket_utils.cc rev 1.34 I took a look at the code and compare it with FreeBSD 6.1 behaviour and I found out that the 64 bits LSB of netmask in rti_info[RTAX_NETMASK] in RTM_ADD or RTM_DELETE or RTM_CHANGE are garbage. It doesn't return ffff:ffff:ffff:ffff:: for an /64 entry, but rather ffff:ffff:ffff:ffff::SOME:GARBAGE:HERE. I got this kind of messages sometimes, where the prefixlen is more than 64: [ 2006/08/21 10:56:42 ERROR xorp_fea:63667 FEA +550 xrl_fti.cc send_fib_client_route_change_cb ] Error sending route change to fib2mrib: 102 Command failed Cannot delete route for A:B:C:D::/65: no such route [ 2006/08/21 10:56:42 WARNING xorp_fib2mrib XrlFib2mribTarget ] Handling method for fea_fib_client/0.1/delete_route6 failed: XrlCmdError 102 Command failed Cannot delete route for A:B:C:D::/65: no such route So I believe the value has to be masked. (my comments start with //XXX) Snippet from fea/routing_socket_utils.cc // // Get the destination mask length // if ( (sa = rti_info[RTAX_NETMASK]) != NULL) { //XXX <--- Should mask here? dst_mask_len = RtmUtils::get_sock_mask_len(family, sa); //XXX or if (dst_mask_len > 64) dst_mask_len = 64; here? } regards, -- From pavlin at icir.org Mon Aug 21 17:27:24 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 21 Aug 2006 17:27:24 -0700 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: Message from "A.H.T" of "Mon, 21 Aug 2006 16:01:30 +0900." <4250f3610608210001n5e5c5275v84fcdc6016f495d5@mail.gmail.com> Message-ID: <200608220027.k7M0RO0v054230@possum.icir.org> > I took a look at the code and compare it with FreeBSD 6.1 behaviour > and I found out that the 64 bits LSB of netmask in > rti_info[RTAX_NETMASK] in RTM_ADD or RTM_DELETE or RTM_CHANGE are > garbage. It doesn't return ffff:ffff:ffff:ffff:: for an /64 entry, but > rather ffff:ffff:ffff:ffff::SOME:GARBAGE:HERE. > I got this kind of messages sometimes, where the prefixlen is more than 64: > > [ 2006/08/21 10:56:42 ERROR xorp_fea:63667 FEA +550 xrl_fti.cc > send_fib_client_route_change_cb ] Error sending route change to > fib2mrib: 102 Command failed Cannot delete route for A:B:C:D::/65: no > such route > [ 2006/08/21 10:56:42 WARNING xorp_fib2mrib XrlFib2mribTarget ] > Handling method for fea_fib_client/0.1/delete_route6 failed: > XrlCmdError 102 Command failed Cannot delete route for A:B:C:D::/65: > no such route Interesting. Could you send me the "route add/change/delete" commands how to replicate the problem. > So I believe the value has to be masked. (my comments start with //XXX) > > Snippet from fea/routing_socket_utils.cc > // > // Get the destination mask length > // > if ( (sa = rti_info[RTAX_NETMASK]) != NULL) { //XXX <--- Should mask here? > dst_mask_len = RtmUtils::get_sock_mask_len(family, sa); > //XXX or if (dst_mask_len > 64) dst_mask_len = 64; here? > } This might not be the right solution, because sometimes the IPv6 prefix length can be legitimately bigger than 64. E.g., the loopback ::1 address has prefix length of 128. Thanks, Pavlin From solca at guug.org Tue Aug 22 05:27:41 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 07:27:41 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs Message-ID: <20060822122741.GA24913@guug.org> FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP but BGP still don't respect the next-hop parameter so still using quagga and trying xorp for PIM-SM: What does this warning means? [ 2006/08/22 07:15:48 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: upstream neighbor for RP 200.0.204.169 for group 239.255.255.254: not found When issuing in xorpsh 'show pim mrib' I get in xorpsh: ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": terminated with signal 11. And in daemons: [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +338 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error I have a lot of IP addresses in various NICs, the PIM register messages comes from the RP connected interface but some registers comes from the last IP address from the last interface, weird, and some messages comes correctly from the RP connected interface. -otto From solca at guug.org Tue Aug 22 05:41:16 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 07:41:16 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <20060822122741.GA24913@guug.org> References: <20060822122741.GA24913@guug.org> Message-ID: <20060822124116.GB24913@guug.org> On Tue, Aug 22, 2006 at 07:27:41AM -0500, Otto Solares wrote: > FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP > but BGP still don't respect the next-hop parameter so still using > quagga and trying xorp for PIM-SM: > > What does this warning means? > > [ 2006/08/22 07:15:48 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: upstream neighbor for RP 200.0.204.169 for group 239.255.255.254: not found > > When issuing in xorpsh 'show pim mrib' I get in xorpsh: > > ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": terminated with signal 11. > > And in daemons: > > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +338 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error > > I have a lot of IP addresses in various NICs, the PIM register messages > comes from the RP connected interface but some registers comes from the > last IP address from the last interface, weird, and some messages comes > correctly from the RP connected interface. Sorry I get this errors too don't know why are they triggered: [ 2006/08/22 07:39:25 ERROR xorp_fea:15938 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted [ 2006/08/22 07:39:25 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted [ 2006/08/22 07:39:25 ERROR xorp_pimsm4:15943 PIM +2623 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted Thank you! -otto From pavlin at icir.org Tue Aug 22 09:05:00 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 09:05:00 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 07:27:41 CDT." <20060822122741.GA24913@guug.org> Message-ID: <200608221605.k7MG50hF073619@possum.icir.org> > FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP > but BGP still don't respect the next-hop parameter so still using > quagga and trying xorp for PIM-SM: > > What does this warning means? > > [ 2006/08/22 07:15:48 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: upstream neighbor for RP 200.0.204.169 for group 239.255.255.254: not found Your XORP router wants to send (*,G) Join message toward the RP (200.0.204.169), but the next-hop router toward it is not PIM-SM capable (or simply there is no next-hop router). Do you see this error all the time or only on startup? If it is only on startup, then it is probably a transient condition (until the MRIB information or the PIM-SM neighborhood information has reached PIM-SM process). Otherwise, to debug the problem, first you need to find the IP address of the next-hop (unicast) router toward 200.0.204.169. After that you need to double-check whether that router is indeed running PIM-SM. If it is running PIM-SM, then you need to find why the XORP router doesn't see the PIM-SM neighborhood info about the upstream. > When issuing in xorpsh 'show pim mrib' I get in xorpsh: > > ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": terminated with signal 11. This means that the above process has terminated by SIGSEGV which is not good. Do you see this every time you execute "show pim mrib"? Also, do you see it when executing other "show pim" commands? Finally, how many forwarding entries are in the kernel when you run "show pim mrib" and it fails. > And in daemons: > > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +338 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error Those errors are probably related to the SIGSEGV termination of the above command. > I have a lot of IP addresses in various NICs, the PIM register messages > comes from the RP connected interface but some registers comes from the > last IP address from the last interface, weird, and some messages comes > correctly from the RP connected interface. Sorry, I don't understand the above, so can you provide some additional info. E.g., are you observing this in the XORP router that is also the RP? Also, are you saying that some of the PIM Register messages arrive with destination IP address of the advertised RP address, but other PIM Register messages come with a different destination address? Please clarify. Thanks, Pavlin From pavlin at icir.org Tue Aug 22 09:13:30 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 09:13:30 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 07:41:16 CDT." <20060822124116.GB24913@guug.org> Message-ID: <200608221613.k7MGDUmi073721@possum.icir.org> > Sorry I get this errors too don't know why are they triggered: > > [ 2006/08/22 07:39:25 ERROR xorp_fea:15938 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > [ 2006/08/22 07:39:25 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > [ 2006/08/22 07:39:25 ERROR xorp_pimsm4:15943 PIM +2623 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted Do you have any firewall rules installed? E.g., I found the following email from someone who was having a similar problem that was fixed by fixing some of the firewall rules, though it was on FreeBSD: http://lists.freebsd.org/pipermail/freebsd-pf/2006-June/002260.html Also, do you have a matching forwarding entry for destination 200.0.204.169? Regards, Pavlin From pavlin at icir.org Tue Aug 22 09:30:19 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 09:30:19 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 07:27:41 CDT." <20060822122741.GA24913@guug.org> Message-ID: <200608221630.k7MGUJiM074038@possum.icir.org> > FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP > but BGP still don't respect the next-hop parameter so still using > quagga and trying xorp for PIM-SM: Forgot to ask. Can you provide more details about the issue with the XORP BGP next-hop parameter? Thanks, Pavlin From solca at guug.org Tue Aug 22 12:54:16 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 14:54:16 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <200608221613.k7MGDUmi073721@possum.icir.org> References: <20060822124116.GB24913@guug.org> <200608221613.k7MGDUmi073721@possum.icir.org> Message-ID: <20060822195416.GB12359@guug.org> On Tue, Aug 22, 2006 at 09:13:30AM -0700, Pavlin Radoslavov wrote: > > Sorry I get this errors too don't know why are they triggered: > > > > [ 2006/08/22 07:39:25 ERROR xorp_fea:15938 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > > [ 2006/08/22 07:39:25 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > > [ 2006/08/22 07:39:25 ERROR xorp_pimsm4:15943 PIM +2623 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > > Do you have any firewall rules installed? Yes, in fact is a router/firewall. > E.g., I found the following email from someone who was having a > similar problem that was fixed by fixing some of the firewall rules, > though it was on FreeBSD: > http://lists.freebsd.org/pipermail/freebsd-pf/2006-June/002260.html I'm pretty sure all PIM/IGMP traffic (incomming, outgoing and forwarded) is accepted. > Also, do you have a matching forwarding entry for destination > 200.0.204.169? Nope, it can reach that IP by means of the default gateway. -otto From solca at guug.org Tue Aug 22 13:13:29 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 15:13:29 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <200608221605.k7MG50hF073619@possum.icir.org> References: <20060822122741.GA24913@guug.org> <200608221605.k7MG50hF073619@possum.icir.org> Message-ID: <20060822201329.GC12359@guug.org> On Tue, Aug 22, 2006 at 09:05:00AM -0700, Pavlin Radoslavov wrote: > > FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP > > but BGP still don't respect the next-hop parameter so still using > > quagga and trying xorp for PIM-SM: > > > > What does this warning means? > > > > [ 2006/08/22 07:15:48 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: upstream neighbor for RP 200.0.204.169 for group 239.255.255.254: not found > > Your XORP router wants to send (*,G) Join message toward the RP > (200.0.204.169), but the next-hop router toward it is not PIM-SM > capable (or simply there is no next-hop router). There is next-hop router but PIM-SM is disabled. See below why. > Do you see this error all the time or only on startup? If it is only > on startup, then it is probably a transient condition (until the > MRIB information or the PIM-SM neighborhood information has reached > PIM-SM process). I see it all the time. > Otherwise, to debug the problem, first you need to find the IP > address of the next-hop (unicast) router toward 200.0.204.169. > After that you need to double-check whether that router is indeed > running PIM-SM. If it is running PIM-SM, then you need to find why > the XORP router doesn't see the PIM-SM neighborhood info about the > upstream. My IP addres toward the RP (200.0.204.169) is 10.10.26.7, my (unicast) next-hop router is 10.10.26.14 which have another NIC with 200.0.204.170 and it's next-hop router is my RP 200.0.204.169. What is happening here is that my RP is in another net not directly attached to my DR and my next-hop router is PIM-SM capable but is not enabled because I don't want my next-hop router to be the RP, because there is no MSDP implementation for Linux I need the other router be the RP so he can exchange my multicast info with other MSDP routers. I think is a valid implementation. > > When issuing in xorpsh 'show pim mrib' I get in xorpsh: > > > > ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": terminated with signal 11. > > This means that the above process has terminated by SIGSEGV which is > not good. > Do you see this every time you execute "show pim mrib"? Yes, every time. > Also, do you see it when executing other "show pim" commands? No, I try all others and everything works as expected, just the above that trigger the errors. > Finally, how many forwarding entries are in the kernel when you run > "show pim mrib" and it fails. Like 10,000 for IPv4 and 700 for IPv6 (IPv6 is not enabled). > > And in daemons: > > > > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 > > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104) > > [ 2006/08/22 07:17:08 ERROR xorp_pimsm4:15829 XRL +338 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error > > Those errors are probably related to the SIGSEGV termination of the > above command. Sorry for not being clear, what I am saying is that is part of the problem but the errors are generated in the daemons, so clearly they are related. > > I have a lot of IP addresses in various NICs, the PIM register messages > > comes from the RP connected interface but some registers comes from the > > last IP address from the last interface, weird, and some messages comes > > correctly from the RP connected interface. > > Sorry, I don't understand the above, so can you provide some > additional info. > E.g., are you observing this in the XORP router that is also the RP? > Also, are you saying that some of the PIM Register messages arrive > with destination IP address of the advertised RP address, but other > PIM Register messages come with a different destination address? > Please clarify. Sorry for no being clear, here is where my english has an end :) anyway will try to explain as is a very weird condition: As mentioned above my IP address in the interface connected towards the RP is 10.10.26.7, in another NIC I have like 126 IP public addresses but that NIC is completely disabled in XORP, what I am seeing is this: * some PIM-register comes from 10.10.26.7 with destination my RP (which is perfect). * some PIM-register comes from 168.234.203.126 with destination my RP, the source is an IP in the NIC disabled in XORP, and from the 126 IP addresses in that disabled (in XORP) NIC is using the last address not the first as would be the normal in any case. I think this is very weird as all PIM-register always should come from the primary IP in the NIC connected towards the RP (which by the way is something you fix some time ago) and not come from an IP address in another NIC specially a disabled one, this seems to me like corruption in structures or something like that. Thanks! -otto From solca at guug.org Tue Aug 22 13:26:38 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 15:26:38 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <200608221630.k7MGUJiM074038@possum.icir.org> References: <20060822122741.GA24913@guug.org> <200608221630.k7MGUJiM074038@possum.icir.org> Message-ID: <20060822202638.GD12359@guug.org> On Tue, Aug 22, 2006 at 09:30:19AM -0700, Pavlin Radoslavov wrote: > > FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP > > but BGP still don't respect the next-hop parameter so still using > > quagga and trying xorp for PIM-SM: > > Forgot to ask. > Can you provide more details about the issue with the XORP BGP > next-hop parameter? As I report sometime ago, I can import nicely all 10,000 routes into XORP via BGP, but I have 2 problems: * My setup is iBGP (my ASN and my peer ASN is the same), XORP say another router have this ASN. If is iBGP it should accept this condition. * When peering with the route-reflector router (iBGP) XORP sends the messages with next-hop = some primary address in another NIC, it should send as PIM-SM works which sends it's messages using the "primary" address towards the RP, just in this case it should use the address toward the BGP router, In quagga this is achieved with: neighbor 10.10.26.14 update-source 10.10.26.7 XORP is using 168.234.203.2 as source, quagga is using 10.10.26.7 * Linux have notion of primary address and secondary addresses (ip a), XORP chooses the first numerically ordered IP address in an interface to be the primary address for sockets and stuff, it should pick the Linux primary address, this can be seen in xorpsh when issuing 'show * interface address". This is not a serious problem as one can rearrange the IPs in your net so the first numerically address match the Linux primary address but anyway is a problem. Hope I have been clear this time. Thanks! -otto From solca at guug.org Tue Aug 22 13:28:38 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 15:28:38 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <20060822195416.GB12359@guug.org> References: <20060822124116.GB24913@guug.org> <200608221613.k7MGDUmi073721@possum.icir.org> <20060822195416.GB12359@guug.org> Message-ID: <20060822202838.GE12359@guug.org> On Tue, Aug 22, 2006 at 02:54:16PM -0500, Otto Solares wrote: > On Tue, Aug 22, 2006 at 09:13:30AM -0700, Pavlin Radoslavov wrote: > > Also, do you have a matching forwarding entry for destination > > 200.0.204.169? > > Nope, it can reach that IP by means of the default gateway. Sorry this is untrue, I have an entry learned via BGP: 200.0.204.0/24 via 10.10.26.14 dev eth6 proto zebra equalize -otto From atanu at ICSI.Berkeley.EDU Tue Aug 22 15:06:13 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 22 Aug 2006 15:06:13 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 15:26:38 CDT." <20060822202638.GD12359@guug.org> Message-ID: <65081.1156284373@tigger.icir.org> Hi, I am having difficulty understanding the problem my comments/questions are inline below. >>>>> "Otto" == Otto Solares writes: Otto> On Tue, Aug 22, 2006 at 09:30:19AM -0700, Pavlin Radoslavov Otto> wrote: >> > FYI I fetch latest CVS and tried PIM-SM multicast routing and >> BGP > but BGP still don't respect the next-hop parameter so still >> using > quagga and trying xorp for PIM-SM: >> >> Forgot to ask. Can you provide more details about the issue with >> the XORP BGP next-hop parameter? Otto> As I report sometime ago, I can import nicely all 10,000 Otto> routes into XORP via BGP, but I have 2 problems: Otto> * My setup is iBGP (my ASN and my peer ASN is the same), XORP Otto> say another router have this ASN. If is iBGP it should accept Otto> this condition. How exactly is this failure manifesting itself? Otto> * When peering with the route-reflector router (iBGP) XORP Otto> sends the messages with next-hop = some primary address in Otto> another NIC, it should send as PIM-SM works which sends it's Otto> messages using the "primary" address towards the RP, just in Otto> this case it should use the address toward the BGP router, In Otto> quagga this is achieved with: Otto> neighbor 10.10.26.14 update-source 10.10.26.7 Otto> XORP is using 168.234.203.2 as source, quagga is using Otto> 10.10.26.7 When sending a message on an internal peering the NEXT_HOP should not be rewritten (unless the route was internally generated). If XORP is rewritting the NEXT_HOP this is incorrect. It seems that in your quagga example that you are explicitly setting the NEXT_HOP. If you want to set the NEXT_HOP values in XORP then you should be able to use policy to rewrite the NEXT_HOP, there is an example on Page 100 of the user manual that should provide hints. Otto> * Linux have notion of primary address and secondary addresses Otto> (ip a), XORP chooses the first numerically ordered IP address Otto> in an interface to be the primary address for sockets and Otto> stuff, it should pick the Linux primary address, this can be Otto> seen in xorpsh when issuing 'show * interface address". This Otto> is not a serious problem as one can rearrange the IPs in your Otto> net so the first numerically address match the Linux primary Otto> address but anyway is a problem. When the BGP rules dictate that a NEXT_HOP should be rewritten it will always uses the configured value, never the first address on an interface. When an address needs to be choosen we have tried very hard to require the user to specify it. Otto> Hope I have been clear this time. I think that we are getting closer. Atanu. From pavlin at icir.org Tue Aug 22 16:48:10 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 16:48:10 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 14:54:16 CDT." <20060822195416.GB12359@guug.org> Message-ID: <200608222348.k7MNmAd9077712@possum.icir.org> Otto Solares wrote: > On Tue, Aug 22, 2006 at 09:13:30AM -0700, Pavlin Radoslavov wrote: > > > Sorry I get this errors too don't know why are they triggered: > > > > > > [ 2006/08/22 07:39:25 ERROR xorp_fea:15938 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > > > [ 2006/08/22 07:39:25 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > > > [ 2006/08/22 07:39:25 ERROR xorp_pimsm4:15943 PIM +2623 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 192.168.10.1 to 200.0.204.169 on vif eth3.10: sendmsg(proto 103 size 28 from 192.168.10.1 to 200.0.204.169 on vif eth3.10) failed: Operation not permitted > > > > Do you have any firewall rules installed? > > Yes, in fact is a router/firewall. > > > E.g., I found the following email from someone who was having a > > similar problem that was fixed by fixing some of the firewall rules, > > though it was on FreeBSD: > > http://lists.freebsd.org/pipermail/freebsd-pf/2006-June/002260.html > > I'm pretty sure all PIM/IGMP traffic (incomming, outgoing and forwarded) > is accepted. As indicated in the above cited email, the problem that person had was fixed by appending "allow-opts" to the relevant rules. This might not apply for your case, but is something to start looking at. The simplest thing to do is to disable all firewall rules (for testing purpose). > > Also, do you have a matching forwarding entry for destination > > 200.0.204.169? > > Nope, it can reach that IP by means of the default gateway. OK. The default forwarding entry is also a matching forwarding entry :) Regards, Pavlin From pavlin at icir.org Tue Aug 22 16:53:59 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 16:53:59 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 15:28:38 CDT." <20060822202838.GE12359@guug.org> Message-ID: <200608222353.k7MNrx3p077781@possum.icir.org> > On Tue, Aug 22, 2006 at 02:54:16PM -0500, Otto Solares wrote: > > On Tue, Aug 22, 2006 at 09:13:30AM -0700, Pavlin Radoslavov wrote: > > > Also, do you have a matching forwarding entry for destination > > > 200.0.204.169? > > > > Nope, it can reach that IP by means of the default gateway. > > Sorry this is untrue, I have an entry learned via BGP: > > 200.0.204.0/24 via 10.10.26.14 dev eth6 proto zebra equalize OK, it probably doesn't matter which particular forwarding entry is used, as long as there is one. If the firewall rules are not the issue, you can try running XORP only without zebra/quagga and install a static route toward the RP. This will tell you whether the error is because of something odd with the forwarding entries. Pavlin From solca at guug.org Tue Aug 22 17:41:06 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 19:41:06 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <200608222353.k7MNrx3p077781@possum.icir.org> References: <20060822202838.GE12359@guug.org> <200608222353.k7MNrx3p077781@possum.icir.org> Message-ID: <20060823004106.GA19348@guug.org> On Tue, Aug 22, 2006 at 04:53:59PM -0700, Pavlin Radoslavov wrote: > > On Tue, Aug 22, 2006 at 02:54:16PM -0500, Otto Solares wrote: > > > On Tue, Aug 22, 2006 at 09:13:30AM -0700, Pavlin Radoslavov wrote: > > > > Also, do you have a matching forwarding entry for destination > > > > 200.0.204.169? > > > > > > Nope, it can reach that IP by means of the default gateway. > > > > Sorry this is untrue, I have an entry learned via BGP: > > > > 200.0.204.0/24 via 10.10.26.14 dev eth6 proto zebra equalize > > OK, it probably doesn't matter which particular forwarding entry is > used, as long as there is one. > > If the firewall rules are not the issue, you can try running XORP > only without zebra/quagga and install a static route toward the RP. > This will tell you whether the error is because of something odd > with the forwarding entries. I think my problems are related to the fact that my RP is not my neighbor. Hopefully now that XORP supports SSM in PIM-SM for IPv4 maybe I don't need MSDP and I could enable PIM in my next-hop router. I have this: My_router <--> NREN_router <--> Internet2_router Now my RP is the Internet2 router, if I configured SSM in My_router and in NREN_router and put as RP the NREN_router how the NREN_router will exchange multicast sessions without MSDP with the Internet2_router? Can this work? Thanks a lot! I'm completely newbee to all this multicast thing. -otto From pavlin at icir.org Tue Aug 22 17:43:01 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 17:43:01 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 15:13:29 CDT." <20060822201329.GC12359@guug.org> Message-ID: <200608230043.k7N0h1oU078276@possum.icir.org> > On Tue, Aug 22, 2006 at 09:05:00AM -0700, Pavlin Radoslavov wrote: > > > FYI I fetch latest CVS and tried PIM-SM multicast routing and BGP > > > but BGP still don't respect the next-hop parameter so still using > > > quagga and trying xorp for PIM-SM: > > > > > > What does this warning means? > > > > > > [ 2006/08/22 07:15:48 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: upstream neighbor for RP 200.0.204.169 for group 239.255.255.254: not found > > > > Your XORP router wants to send (*,G) Join message toward the RP > > (200.0.204.169), but the next-hop router toward it is not PIM-SM > > capable (or simply there is no next-hop router). > > There is next-hop router but PIM-SM is disabled. See below why. If the next-hop MRIB router toward the RP is not running PIM-SM, then the PIM-SM routing won't work.This is how the protocol operates. Obviously, this doesn't apply to SSM which doesn't have the concept of RP. > My IP addres toward the RP (200.0.204.169) is 10.10.26.7, my (unicast) > next-hop router is 10.10.26.14 which have another NIC with > 200.0.204.170 and it's next-hop router is my RP 200.0.204.169. > > What is happening here is that my RP is in another net not directly > attached to my DR and my next-hop router is PIM-SM capable but is > not enabled because I don't want my next-hop router to be the RP, > because there is no MSDP implementation for Linux I need the other > router be the RP so he can exchange my multicast info with other > MSDP routers. I think is a valid implementation. If I understand correctly, your concern is that by enabling PIM-SM on your next-hop router, that router will become an RP. You can have your next-hop router running PIM-SM, and it doesn't have to be a Candidate-RP. Simply make sure that that it doesn't have "cand-bsr" or "cand-rp" section (inside the "bootstrap" section), and that any of its IP addresses is listed inside the "static-rps" section. Of course, you want all your PIM-SM routers to agree which one is the RP. One possible solution is to configure it as a static RP. E.g., add the following (or the equivalent) to all your PIM-SM routers: protocols { pimsm4 { ... static-rps { rp 200.0.204.169 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } ... } } Alternatively, use the Bootstrap mechanism, and configure only the RP as a Cand-BSR and Cand-RP: protocols { pimsm4 { ... bootstrap { cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-addr: 200.0.204.169 /* bsr-priority: 1 */ /* hash-mask-len: 30 */ } } cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-addr: 200.0.204.169 /* rp-priority: 192 */ /* rp-holdtime: 150 */ } } } ... } } > > > When issuing in xorpsh 'show pim mrib' I get in xorpsh: > > > > > > ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": terminated with signal 11. > > > > This means that the above process has terminated by SIGSEGV which is > > not good. > > Do you see this every time you execute "show pim mrib"? > > Yes, every time. > > > Also, do you see it when executing other "show pim" commands? > > No, I try all others and everything works as expected, just the above > that trigger the errors. > > > Finally, how many forwarding entries are in the kernel when you run > > "show pim mrib" and it fails. > > Like 10,000 for IPv4 and 700 for IPv6 (IPv6 is not enabled). The mechanism used by "send_cli_processor_xrl" to obtain the MRIB information is not scalable, hence probably this is the reason it coredumps when showing large MRIB output. To verify that, can you try running "show pim mrib" when there are few entries (tens or lower hundreds) and see whether it still coredumps. The simplest solution is not to use "show pim mrib" when the MRIB has lots of entries, but use the equivalent "show route table ipv4 multicast final". In the future, the "send_cli_processor_xrl" mechanism will be retired and replaced with a better mechanism. > > > I have a lot of IP addresses in various NICs, the PIM register messages > > > comes from the RP connected interface but some registers comes from the > > > last IP address from the last interface, weird, and some messages comes > > > correctly from the RP connected interface. > > > > Sorry, I don't understand the above, so can you provide some > > additional info. > > E.g., are you observing this in the XORP router that is also the RP? > > Also, are you saying that some of the PIM Register messages arrive > > with destination IP address of the advertised RP address, but other > > PIM Register messages come with a different destination address? > > Please clarify. > > Sorry for no being clear, here is where my english has an end :) > anyway will try to explain as is a very weird condition: > > As mentioned above my IP address in the interface connected towards > the RP is 10.10.26.7, in another NIC I have like 126 IP public > addresses but that NIC is completely disabled in XORP, what I am > seeing is this: > > * some PIM-register comes from 10.10.26.7 with destination my RP > (which is perfect). > * some PIM-register comes from 168.234.203.126 with destination my > RP, the source is an IP in the NIC disabled in XORP, and from the > 126 IP addresses in that disabled (in XORP) NIC is using the > last address not the first as would be the normal in any case. For all PIM Register messages, the source address should be one of the addresses that belong to the interface toward the RP. If the interface is not enabled, then you should see the following warning: XLOG_WARNING("RX WHOLEPKT signal from %s: vif_index = %d " "src = %s dst = %s len = %u: " "no RPF interface toward the RP (%s)", src_module_instance_name.c_str(), vif_index, cstring(src), cstring(dst), XORP_UINT_CAST(rcvlen), cstring(*rp_addr_ptr)); Can you double-check with "show pim interface" that the interface with address 168.234.203.126 is indeed disabled. If it is indeed, disabled, can you stop running PIM-SM altogether on the router with address 168.234.203.126 and see whether the RP is still getting PIM Registers with that source address (this is to double-check there is no misconfigured PIM-SM router somewhere with that same IP address). > I think this is very weird as all PIM-register always should come > from the primary IP in the NIC connected towards the RP (which by > the way is something you fix some time ago) and not come from > an IP address in another NIC specially a disabled one, this seems > to me like corruption in structures or something like that. Currently, XORP doesn't support the concept of primary IP address (yet), so it will choose one of the addresses. Though, yes, the source address should be from the interface toward the RP, and only if that interface is enabled and running PIM-SM. If there is no misconfigured PIM-SM router with same 168.234.203.126, then you can try to debug the issue by adding some XLOG_INFO() statements around line 167 in pim/pim_mrt_mfc.cc (rev 1.35) on the XORP router with address 168.234.203.126: // // Send a PIM Register to the RP using the RPF vif toward it // pim_vif = pim_node().pim_vif_rpf_find(*rp_addr_ptr); E.g., add a statement like: XLOG_INFO("Sending PIM Register on vif %s (%u): " "vif_addr = %s RP = %s inner_src = %s inner_dst = %s", pim_vif->name().c_str(), pim_vif->is_up(), cstring(pim_vif->domain_wide_addr()), cstring(*rp_addr_ptr), cstring(src), cstring(dst), Thanks, Pavlin From pavlin at icir.org Tue Aug 22 17:54:44 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 17:54:44 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 19:41:06 CDT." <20060823004106.GA19348@guug.org> Message-ID: <200608230054.k7N0sipS078458@possum.icir.org> > I think my problems are related to the fact that my RP is not > my neighbor. > > Hopefully now that XORP supports SSM in PIM-SM for IPv4 maybe I > don't need MSDP and I could enable PIM in my next-hop router. > > I have this: > > My_router <--> NREN_router <--> Internet2_router > > Now my RP is the Internet2 router, if I configured SSM in > My_router and in NREN_router and put as RP the NREN_router how > the NREN_router will exchange multicast sessions without MSDP > with the Internet2_router? Can this work? You must run PIM-SM on MREN_router even if you are going to use SSM only. As I mentioned in one of my earlier emails, you don't have to configure MREN_router to be an RP. Instead, configure both My_router and MREN_router (e.g., using static-rps entry) to consider Internet2_router as the RP. You need MSDP if you have your own PIM-SM domain with your own set of RPs, and you want to exchange that info with other PIM-SM domains. If Internet2_router is already running MSDP for example, then you just become part of the Internet2_route's PIM-SM domain and you don't need MSDP running on My_router or MREN_router. Regards, Pavlin From solca at guug.org Tue Aug 22 18:47:20 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 20:47:20 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <200608230054.k7N0sipS078458@possum.icir.org> References: <20060823004106.GA19348@guug.org> <200608230054.k7N0sipS078458@possum.icir.org> Message-ID: <20060823014720.GB19348@guug.org> On Tue, Aug 22, 2006 at 05:54:44PM -0700, Pavlin Radoslavov wrote: > You must run PIM-SM on MREN_router even if you are going to use SSM > only. As I mentioned in one of my earlier emails, you don't have to > configure MREN_router to be an RP. Instead, configure both My_router > and MREN_router (e.g., using static-rps entry) to consider > Internet2_router as the RP. > > You need MSDP if you have your own PIM-SM domain with your own set > of RPs, and you want to exchange that info with other PIM-SM > domains. If Internet2_router is already running MSDP for example, > then you just become part of the Internet2_route's PIM-SM domain and > you don't need MSDP running on My_router or MREN_router. Excellent news! Well it appears that the Internet2_router (cisco) finally see something, I don't get the neighbor errors anymore, will test tomorrow with the Internet2 people to see if a multicast transmition actually works. Your advise have helped me a lot! Just for the record, one needs PIM in all interfaces where multicast packets will flow, why is that technically necessary just for curiosity? Now I'm getting lots of this errors just with differents interfaces and differents from IP addresses: [ 2006/08/22 20:36:07 ERROR xorp_pimsm4:30195 PIM +2623 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.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted If you see the 200.0.204.169 router is in eth6, why XORP try to send from 10.0.2.1 to 200.0.204.169 on eth4? that obviously will fail and probably is why is not permitted, maybe is the source of the other problem when I see bogus from IP addresses in PIM-register messages. It should send to 200.0.204.169 using the primary IP in eth6 which is the interface towards the RP as we have talked previously. 989.877636 168.234.203.126 -> 200.0.204.169 PIMv2 Register 989.941391 200.0.204.169 -> 168.234.203.126 PIMv2 Register-stop 1576.736525 168.234.203.5 -> 200.0.204.169 PIMv2 Register 1576.800376 200.0.204.169 -> 168.234.203.5 PIMv2 Register-stop What Register-stop packets means? And as you can see there are two different IP sources for PIM Register packets, that is the problem I mentioned above about bogus sources. Thanks a lot!!! -otto From solca at guug.org Tue Aug 22 19:09:29 2006 From: solca at guug.org (Otto Solares) Date: Tue, 22 Aug 2006 21:09:29 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <20060823014720.GB19348@guug.org> References: <20060823004106.GA19348@guug.org> <200608230054.k7N0sipS078458@possum.icir.org> <20060823014720.GB19348@guug.org> Message-ID: <20060823020929.GC19348@guug.org> On Tue, Aug 22, 2006 at 08:47:20PM -0500, Otto Solares wrote: > Now I'm getting lots of this errors just with differents interfaces and > differents from IP addresses: > > [ 2006/08/22 20:36:07 ERROR xorp_pimsm4:30195 PIM +2623 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.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted I see now different warnings and errors if that can help: [ 2006/08/22 20:42:23 ERROR xorp_fea:30185 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 192.168.9.1 to 200.0.204.169 on vif eth3.9) failed: Operation not permitted [ 2006/08/22 20:42:23 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 192.168.9.1 to 200.0.204.169 on vif eth3.9: sendmsg(proto 103 size 28 from 192.168.9.1 to 200.0.204.169 on vif eth3.9) failed: Operation not permitted [ 2006/08/22 20:42:23 ERROR xorp_pimsm4:30195 PIM +2623 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 192.168.9.1 to 200.0.204.169 on vif eth3.9: sendmsg(proto 103 size 28 from 192.168.9.1 to 200.0.204.169 on vif eth3.9) failed: Operation not permitted [ 2006/08/22 20:42:32 ERROR xorp_fea:30185 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 172.16.0.1 to 200.0.204.169 on vif eth2) failed: Operation not permitted [ 2006/08/22 20:42: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 172.16.0.1 to 200.0.204.169 on vif eth2: sendmsg(proto 103 size 28 from 172.16.0.1 to 200.0.204.169 on vif eth2) failed: Operation not permitted [ 2006/08/22 20:42:32 ERROR xorp_pimsm4:30195 PIM +2623 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 172.16.0.1 to 200.0.204.169 on vif eth2: sendmsg(proto 103 size 28 from 172.16.0.1 to 200.0.204.169 on vif eth2) failed: Operation not permitted -otto From pavlin at icir.org Tue Aug 22 21:55:08 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 21:55:08 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 21:09:29 CDT." <20060823020929.GC19348@guug.org> Message-ID: <200608230455.k7N4t8Qq080207@possum.icir.org> > > Now I'm getting lots of this errors just with differents interfaces and > > differents from IP addresses: > > > > [ 2006/08/22 20:36:07 ERROR xorp_pimsm4:30195 PIM +2623 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.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted > > I see now different warnings and errors if that can help: Those errors and warnings are similar to the previous. Please try the suggestions I described in the previous emails. Pavlin > [ 2006/08/22 20:42:23 ERROR xorp_fea:30185 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 192.168.9.1 to 200.0.204.169 on vif eth3.9) failed: Operation not permitted > [ 2006/08/22 20:42:23 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 192.168.9.1 to 200.0.204.169 on vif eth3.9: sendmsg(proto 103 size 28 from 192.168.9.1 to 200.0.204.169 on vif eth3.9) failed: Operation not permitted > [ 2006/08/22 20:42:23 ERROR xorp_pimsm4:30195 PIM +2623 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 192.168.9.1 to 200.0.204.169 on vif eth3.9: sendmsg(proto 103 size 28 from 192.168.9.1 to 200.0.204.169 on vif eth3.9) failed: Operation not permitted > [ 2006/08/22 20:42:32 ERROR xorp_fea:30185 MFEA +2236 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 size 28 from 172.16.0.1 to 200.0.204.169 on vif eth2) failed: Operation not permitted > [ 2006/08/22 20:42: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 172.16.0.1 to 200.0.204.169 on vif eth2: sendmsg(proto 103 size 28 from 172.16.0.1 to 200.0.204.169 on vif eth2) failed: Operation not permitted > [ 2006/08/22 20:42:32 ERROR xorp_pimsm4:30195 PIM +2623 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 172.16.0.1 to 200.0.204.169 on vif eth2: sendmsg(proto 103 size 28 from 172.16.0.1 to 200.0.204.169 on vif eth2) failed: Operation not permitted > > -otto > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Aug 22 22:08:08 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Aug 2006 22:08:08 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Tue, 22 Aug 2006 20:47:20 CDT." <20060823014720.GB19348@guug.org> Message-ID: <200608230508.k7N588BY080441@possum.icir.org> > Just for the record, one needs PIM in all interfaces where multicast > packets will flow, why is that technically necessary just for curiosity? Because this is how the PIM-SM protocol operates. E.g., a multicast data packet will be forwarded on an interface only if an explicit Join (PIM-SM or IGMP/MLD) message has been received. > Now I'm getting lots of this errors just with differents interfaces and > differents from IP addresses: > > [ 2006/08/22 20:36:07 ERROR xorp_pimsm4:30195 PIM +2623 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.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted > > If you see the 200.0.204.169 router is in eth6, why XORP try to send > from 10.0.2.1 to 200.0.204.169 on eth4? that obviously will fail and > probably is why is not permitted, maybe is the source of the other > problem when I see bogus from IP addresses in PIM-register messages. If 200.0.204.169 is directly connected to eth6, then eth6 should have been used to transmit the message. The above information is not sufficient to answer why eth4 is used instead. The first thing to check is the MRIB entries, and whether PIM-SM is actually running on the 200.0.204.169 interface. > It should send to 200.0.204.169 using the primary IP in eth6 which is > the interface towards the RP as we have talked previously. > > 989.877636 168.234.203.126 -> 200.0.204.169 PIMv2 Register > 989.941391 200.0.204.169 -> 168.234.203.126 PIMv2 Register-stop > 1576.736525 168.234.203.5 -> 200.0.204.169 PIMv2 Register > 1576.800376 200.0.204.169 -> 168.234.203.5 PIMv2 Register-stop > > What Register-stop packets means? The Register-stop packet is sent by the RP to the DR and indicates that the RP is not interested in receiving PIM Register messages for a particular source and group address. E.g., typically it is sent when there are no (*,G) receivers. > And as you can see there are two different IP sources for PIM Register > packets, that is the problem I mentioned above about bogus sources. The source addresses seem fine: the PIM Register is sent from the DR to the RP, and the PIM Register-Stop is sent from the RP to the DR. Hence, I don't think there is a problem here. Pavlin From alain at ait.ac.th Tue Aug 22 22:29:29 2006 From: alain at ait.ac.th (Alain Fauconnet) Date: Wed, 23 Aug 2006 12:29:29 +0700 Subject: [Xorp-users] troubleshooting wrong route in OSPF? Message-ID: <20060823052929.GN11412@ait.ac.th> Hello readers, Sorry if this sounds a bit like a newbie question, but I've browsed the available documentation and couldn't find any answer to help me diagnose this (like for tracing OSPF advertisements, costs) I have a case of XORP's OSPF installing the wrong route in a simple, single area (0.0.0.0) configuration: a.b.63.4/30 .5 a.b.36.0/24 .1 [4000] ----- [XORP] ------+------[7200] a.b.128.2 .5 .6 | .10 [Zebra] Both the XORP and Zebra boxes are Linux-based, the other boxes are a 7200-series router and a Catalyst 4000-series L3 switch (which doesn't seem to have any relevance here, but just to be complete...) a.b.128.2 is a loopback interface on the 7200. As showem, 3 boxes have an interface in network a.b.36.0/24: Xorp: eth0 is a.b.36.5 Zebra: eth0 is a.b.36.10 7200: FastEthernet2/1 is a.b.36.1 On the XORP box: > ip route get a.b.128.2 a.b.128.2 via a.b.36.10 dev eth0 src a.b.36.5 cache mtu 1500 advmss 1460 which is obviously wrong. Both neighbors are up though: > xorpsh -c 'show ospf4 neighbor' Address Interface State ID Pri Dead a.b.36.10 eth0/eth0 Full a.b.36.10 1 33 a.b.36.1 eth0/eth0 Full a.b.128.8 1 38 a.b.63.5 eth1/eth1 Full a.b.128.6 1 36 So the (2 hops) route advertised by the Zebra box is preferred to the 1 hop route to the Cisco router... how can this be? Where can I go from here to troubleshoot this? I would know on a Cisco box (looking at costs etc.) but I feel helpless with Xorp. Thanks in advance for your time reading this and any tip, even RTFM links. Greets, _Alain_ From solca at guug.org Wed Aug 23 09:34:01 2006 From: solca at guug.org (Otto Solares) Date: Wed, 23 Aug 2006 11:34:01 -0500 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: <200608230508.k7N588BY080441@possum.icir.org> References: <20060823014720.GB19348@guug.org> <200608230508.k7N588BY080441@possum.icir.org> Message-ID: <20060823163401.GA18431@guug.org> On Tue, Aug 22, 2006 at 10:08:08PM -0700, Pavlin Radoslavov wrote: > > Just for the record, one needs PIM in all interfaces where multicast > > packets will flow, why is that technically necessary just for curiosity? > > Because this is how the PIM-SM protocol operates. E.g., a multicast > data packet will be forwarded on an interface only if an explicit > Join (PIM-SM or IGMP/MLD) message has been received. Is this true for SSM model too and for IPv6? Thanks. > > Now I'm getting lots of this errors just with differents interfaces and > > differents from IP addresses: > > > > [ 2006/08/22 20:36:07 ERROR xorp_pimsm4:30195 PIM +2623 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.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted > > > > If you see the 200.0.204.169 router is in eth6, why XORP try to send > > from 10.0.2.1 to 200.0.204.169 on eth4? that obviously will fail and > > probably is why is not permitted, maybe is the source of the other > > problem when I see bogus from IP addresses in PIM-register messages. > > If 200.0.204.169 is directly connected to eth6, then eth6 should > have been used to transmit the message. > The above information is not sufficient to answer why eth4 is used > instead. The first thing to check is the MRIB entries, and whether > PIM-SM is actually running on the 200.0.204.169 interface. PIM-SM is running on all interfaces, as I'm not running BGP in XORP but in Quagga I'm using the fib2mrib to populate it, I can confirm that the URIB is ok and the route to 200.0.204.169 is via eth6, dunno why xorp try to send to 200.0.204.169 via other interfaces, should I check in another place? > > It should send to 200.0.204.169 using the primary IP in eth6 which is > > the interface towards the RP as we have talked previously. > > > > 989.877636 168.234.203.126 -> 200.0.204.169 PIMv2 Register > > 989.941391 200.0.204.169 -> 168.234.203.126 PIMv2 Register-stop > > 1576.736525 168.234.203.5 -> 200.0.204.169 PIMv2 Register > > 1576.800376 200.0.204.169 -> 168.234.203.5 PIMv2 Register-stop > > > > What Register-stop packets means? > > The Register-stop packet is sent by the RP to the DR and indicates > that the RP is not interested in receiving PIM Register messages for > a particular source and group address. > E.g., typically it is sent when there are no (*,G) receivers. Ok. > > And as you can see there are two different IP sources for PIM Register > > packets, that is the problem I mentioned above about bogus sources. > > The source addresses seem fine: the PIM Register is sent from the DR > to the RP, and the PIM Register-Stop is sent from the RP to the DR. > Hence, I don't think there is a problem here. I think it is a problem because there are 2 differents source addresses used by XORP 168.234.203.126 and 168.234.203.5, if I understand correctly XORP will pick _ONE_ time it's primary address (168.234.203.5) and and stick to it for talking to the RP. Other address to talk to the RP is dubious IMO. Thanks. -otto From pavlin at icir.org Wed Aug 23 09:48:52 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 23 Aug 2006 09:48:52 -0700 Subject: [Xorp-users] PIM-SM in xorp cvs In-Reply-To: Message from Otto Solares of "Wed, 23 Aug 2006 11:34:01 CDT." <20060823163401.GA18431@guug.org> Message-ID: <200608231648.k7NGmqb2091164@possum.icir.org> > > > Just for the record, one needs PIM in all interfaces where multicast > > > packets will flow, why is that technically necessary just for curiosity? > > > > Because this is how the PIM-SM protocol operates. E.g., a multicast > > data packet will be forwarded on an interface only if an explicit > > Join (PIM-SM or IGMP/MLD) message has been received. > > Is this true for SSM model too and for IPv6? Thanks. Yes. > > > Now I'm getting lots of this errors just with differents interfaces and > > > differents from IP addresses: > > > > > > [ 2006/08/22 20:36:07 ERROR xorp_pimsm4:30195 PIM +2623 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.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted > > > > > > If you see the 200.0.204.169 router is in eth6, why XORP try to send > > > from 10.0.2.1 to 200.0.204.169 on eth4? that obviously will fail and > > > probably is why is not permitted, maybe is the source of the other > > > problem when I see bogus from IP addresses in PIM-register messages. > > > > If 200.0.204.169 is directly connected to eth6, then eth6 should > > have been used to transmit the message. > > The above information is not sufficient to answer why eth4 is used > > instead. The first thing to check is the MRIB entries, and whether > > PIM-SM is actually running on the 200.0.204.169 interface. > > PIM-SM is running on all interfaces, as I'm not running BGP in XORP > but in Quagga I'm using the fib2mrib to populate it, I can confirm > that the URIB is ok and the route to 200.0.204.169 is via eth6, dunno > why xorp try to send to 200.0.204.169 via other interfaces, should I > check in another place? Try the XLOG_INFO() debug statement I sent you in an earlier email. This might give us some additional info about the issue. Also, one more thing you should try is to run XORP only (without running BGP from quagga or even from XORP itself), and install static routes toward the RP. Then see whether you have the same issue with selecting the RPF interface. > > > It should send to 200.0.204.169 using the primary IP in eth6 which is > > > the interface towards the RP as we have talked previously. > > > > > > 989.877636 168.234.203.126 -> 200.0.204.169 PIMv2 Register > > > 989.941391 200.0.204.169 -> 168.234.203.126 PIMv2 Register-stop > > > 1576.736525 168.234.203.5 -> 200.0.204.169 PIMv2 Register > > > 1576.800376 200.0.204.169 -> 168.234.203.5 PIMv2 Register-stop > > > > > > What Register-stop packets means? > > > > The Register-stop packet is sent by the RP to the DR and indicates > > that the RP is not interested in receiving PIM Register messages for > > a particular source and group address. > > E.g., typically it is sent when there are no (*,G) receivers. > > Ok. > > > > And as you can see there are two different IP sources for PIM Register > > > packets, that is the problem I mentioned above about bogus sources. > > > > The source addresses seem fine: the PIM Register is sent from the DR > > to the RP, and the PIM Register-Stop is sent from the RP to the DR. > > Hence, I don't think there is a problem here. > > I think it is a problem because there are 2 differents source addresses > used by XORP 168.234.203.126 and 168.234.203.5, if I understand > correctly XORP will pick _ONE_ time it's primary address (168.234.203.5) > and and stick to it for talking to the RP. Other address to talk to the > RP is dubious IMO. Yes, sorry, I didn't realize that both 168.234.203.126 and 168.234.203.5 belong to the same XORP router. What is the output of the "show pim interface" and "show pim interface address" for that router? Also, here again please try running XORP with static routes only and see whether it will again select a different source address for each PIM Register message. Thanks, Pavlin From hasso at linux.ee Wed Aug 23 09:57:22 2006 From: hasso at linux.ee (Hasso Tepper) Date: Wed, 23 Aug 2006 19:57:22 +0300 Subject: [Xorp-users] troubleshooting wrong route in OSPF? In-Reply-To: <20060823052929.GN11412@ait.ac.th> References: <20060823052929.GN11412@ait.ac.th> Message-ID: <200608231957.23197.hasso@linux.ee> Alain Fauconnet wrote: > Hello readers, > > Sorry if this sounds a bit like a newbie question, but I've browsed > the available documentation and couldn't find any answer to help me > diagnose this (like for tracing OSPF advertisements, costs) Not enough info - OSPF database would be needed, but there is at least one known bug in Xorp OSPF which might bite you in this situation. http://www.xorp.org/bugzilla/show_bug.cgi?id=564 Btw, I personally think that it's not acceptable to release with such bugs (bug was reported before 1.2) - wrong routes in RIB should be blocker. But that's only my opinion of course. regards, -- Hasso Tepper From ahthamrin at gmail.com Thu Aug 24 22:53:05 2006 From: ahthamrin at gmail.com (A.H.T) Date: Fri, 25 Aug 2006 14:53:05 +0900 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: <200608220027.k7M0RO0v054230@possum.icir.org> References: <4250f3610608210001n5e5c5275v84fcdc6016f495d5@mail.gmail.com> <200608220027.k7M0RO0v054230@possum.icir.org> Message-ID: <4250f3610608242253r72cafd66g3cc3d55181432e08@mail.gmail.com> On 8/22/06, Pavlin Radoslavov wrote: > > Interesting. Could you send me the "route add/change/delete" commands > how to replicate the problem. I added debugging code in routing_socket_utils.cc to show the netmask value. I used route add command to add AAAA:BBBB:fad:dead:bee8::/77 prefix route. After that, zebra deleted AAAA:BBBB:10a::/64 route, but the routing socket sends a netmask with masklen /77, which I believe is what's left from my route add command. %route -n add -inet6 AAAA:BBBB:fad:dead:bee8:: -prefixlen 77 fe80::2e0:81ff:fe02:fa52%em0 add net AAAA:BBBB:fad:dead:bee8::: gateway fe80::2e0:81ff:fe02:fa52%em0 [ 2006/08/25 10:40:44 ERROR xorp_fea:18632 FEA +512 routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 1 prefix AAAA:BBBB:fad:dead:bee8:: mask ffff:ffff:ffff:ffff:fff8:0:603:600 masklen 77 nexthop fe80::2e0:81ff:fe02:fa52 [ 2006/08/25 10:44:03 ERROR xorp_fea:18632 FEA +512 routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 2 prefix AAAA:BBBB:10a:: mask :: masklen 77 nexthop fe80::2e0:81ff:fe02:fa52 [ 2006/08/25 10:44:03 WARNING xorp_fib2mrib XrlFib2mribTarget ] Handling method for fea_fib_client/0.1/delete_route6 failed: XrlCmdError 102 Command failed Cannot delete route for AAAA:BBBB:10a::/77: no such route [ 2006/08/25 10:44:03 ERROR xorp_fea:18632 FEA +550 xrl_fti.cc send_fib_client_route_change_cb ] Error sending route change to fib2mrib: 102 Command failed Cannot delete route for AAAA:BBBB:10a::/77: no such route [ 2006/08/25 10:44:04 ERROR xorp_fea:18632 FEA +512 routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 1 prefix AAAA:BBBB:10a:: mask :: masklen 64 nexthop fe80::2e0:81ff:fe02:fa52 So based on this observation, it seems that the kernel only gives good netmask value in n * 32bits boundary. > This might not be the right solution, because sometimes the IPv6 > prefix length can be legitimately bigger than 64. E.g., the loopback > ::1 address has prefix length of 128. AFAIK, a link prefix in the global unicast routing address space is /64. So there should be no prefixlen > 64, right? Need to confirm with the spec, though. for ::1/128 (host route), isn't it handled by if (rtm->rtm_type & RTF_HOST) { if (dst_mask_len == 0) dst_mask_len = IPvX::addr_bitlen(family); } ? regards, -- From hasso at linux.ee Fri Aug 25 01:31:43 2006 From: hasso at linux.ee (Hasso Tepper) Date: Fri, 25 Aug 2006 11:31:43 +0300 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: <200608220027.k7M0RO0v054230@possum.icir.org> References: <200608220027.k7M0RO0v054230@possum.icir.org> Message-ID: <200608251131.44266.hasso@linux.ee> Pavlin Radoslavov wrote: > This might not be the right solution, because sometimes the IPv6 > prefix length can be legitimately bigger than 64. E.g., the loopback > ::1 address has prefix length of 128. Any address can have prefix length /128. Loopback can have global addresses as well :). Note that although having prefix length longer than /64 seems to be forbidden by RFC3513 for non-000/3 unicast prefixes, using /127 and smaller (but bigger than /64) has gained a lot of operational popularity. There is a mass of discussions about this in the net (search cisco-nsp, nanog etc list archives). Yes, I know /127 is bad idea (see RFC3267 for details), but smaller prefix lengths don't have any operational impact for now in any equipment I know of. So, I think Xorp shouldn't set any restrictions either. With these we could cause a lot of trouble for users while integrating Xorp routers into existing networks. regards, -- Hasso Tepper From alain at ait.ac.th Fri Aug 25 02:31:05 2006 From: alain at ait.ac.th (Alain Fauconnet) Date: Fri, 25 Aug 2006 16:31:05 +0700 Subject: [Xorp-users] troubleshooting wrong route in OSPF? In-Reply-To: <200608231957.23197.hasso@linux.ee> References: <20060823052929.GN11412@ait.ac.th> <200608231957.23197.hasso@linux.ee> Message-ID: <20060825093105.GM8660@ait.ac.th> Hasso, On Wed, Aug 23, 2006 at 07:57:22PM +0300, Hasso Tepper wrote: > Alain Fauconnet wrote: > > Hello readers, > > > > Sorry if this sounds a bit like a newbie question, but I've browsed > > the available documentation and couldn't find any answer to help me > > diagnose this (like for tracing OSPF advertisements, costs) > > Not enough info - OSPF database would be needed, but there is at least one > known bug in Xorp OSPF which might bite you in this situation. > > http://www.xorp.org/bugzilla/show_bug.cgi?id=564 Thanks for your reply. I was thinking about collecting information but again I couldn't find the right commands to get something readable. "show ospf4 database" isn't precisely easy to read (not to me at least - any other command useful for troubleshooting OSPF?) Then I tried a work-around on the Zebra box (make the interface passive in OSPF) but that was taking me nowhere. To do this I had to restart Zebra and... it made the problem go away :-( or is it :-)? Anyway, I couldn't get the information anymore. > Btw, I personally think that it's not acceptable to release with such bugs > (bug was reported before 1.2) - wrong routes in RIB should be blocker. > But that's only my opinion of course. I would think the same and I see that your bug # dates from March already, still new. Guess that means that it hasn't been fixed in the CVS code either, or has it? Well, I'll wait until this happens up again and collect the whole OSPF database this time. Greets, _Alain_ From intel at intrans.baku.az Fri Aug 25 03:52:59 2006 From: intel at intrans.baku.az (Timur Khanjanov) Date: Fri, 25 Aug 2006 15:52:59 +0500 Subject: [Xorp-users] why xorp is too big? Message-ID: <44EED68B.9050506@intrans.baku.az> i've compile xopr 1.3 (little modified port v 1.2 for freebsd) and see that size of package is over 50Mb(unpacked) the freebsd (5,4 nanobsd cutted) + mpd +net-snmp + quagga + perl (trimmed down) all together have size near the same why such significally difference in size between xorp and quagga? or may be I miss something? Sincerely yours Timur From hasso at linux.ee Fri Aug 25 04:07:12 2006 From: hasso at linux.ee (Hasso Tepper) Date: Fri, 25 Aug 2006 14:07:12 +0300 Subject: [Xorp-users] why xorp is too big? In-Reply-To: <44EED68B.9050506@intrans.baku.az> References: <44EED68B.9050506@intrans.baku.az> Message-ID: <200608251407.12281.hasso@linux.ee> Timur Khanjanov wrote: > i've compile xopr 1.3 (little modified port v 1.2 for freebsd) and see > that size of package is over 50Mb(unpacked) Xorp is statically linked. See following thread for more info: http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-September/000493.html regards, -- Hasso Tepper From ramu.avula at gmail.com Mon Aug 28 08:28:58 2006 From: ramu.avula at gmail.com (Ramu k) Date: Mon, 28 Aug 2006 20:58:58 +0530 Subject: [Xorp-users] 211 Reply timed out error Message-ID: Hi , when I am trying to run XORP with more 100 vlan interfaces it is coming out with the following error . Sent xrl got response 211 Reply timed out error Is there any limit on #of interfaces . did anybody tried more than 100 interfaces. can anybody tell what is the meaning of this error . Thanks for any help in this regard. Regards , Ramu.K Detailed error LOG [ 2006/08/28 20:03:00 INFO xorp_rtrmgr:6323 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 [ 2006/08/28 20:03:01 INFO xorp_rtrmgr:6323 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] MFEA enabled [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI enabled [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI started [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] MFEA enabled [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI enabled [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI started [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:44 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 CLI +116 xrl_cli_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 LIBXORP +238 selector.ccremove_ioevent_cb ] Attempting to remove fd = -1 that is outside range of file descriptors 0..73 [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 MFEA +192 xrl_mfea_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 MFEA +192 xrl_mfea_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2006/08/28 20:03:45 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:46 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:47 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:48 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:49 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:50 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:51 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:52 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:53 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:54 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:55 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:56 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:57 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:58 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:59 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:00 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:01 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:02 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:03 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:04 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:05 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:06 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:07 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:08 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:09 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:10 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:11 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:12 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:13 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:14 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +1998 task.cc task_fail ] Shutting down fatally wounded process (interfaces) [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +197 module_manager.cc terminate ] Killing module: interfaces [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: Reconfig of process interfaces caused process to fail. [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +252 master_conf_tree.cc config_done ] Configuration failed: Reconfig of process interfaces caused process to fail. [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +197 module_manager.cc terminate ] Killing module: interfaces [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +747 module_manager.cc done_cb ] Command "/root/xorp-1.2/fea/xorp_fea": terminated with signal 15. [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +285 module_manager.cc module_exited ] Module killed during shutdown: interfaces -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060828/bb417620/attachment.html From pavlin at icir.org Tue Aug 29 10:31:26 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 29 Aug 2006 10:31:26 -0700 Subject: [Xorp-users] 211 Reply timed out error In-Reply-To: Message from "Ramu k" of "Mon, 28 Aug 2006 20:58:58 +0530." Message-ID: <200608291731.k7THVQ3f032169@possum.icir.org> > when I am trying to run XORP with more 100 vlan interfaces > it is coming out with the following error . > > Sent xrl got response 211 Reply timed out error > > Is there any limit on #of interfaces . did anybody tried more than > 100 interfaces. > can anybody tell what is the meaning of this error . I presume it is working for 50 VLAN interfaces, based on the information you sent to the list almost 2 months ago (see the thread with Subject "Too many open files in system"). Do you get same problem if you try with smaller number of VLANs (e.g., 60, 70, 80, 90). It would be interesting to know whether there is an exact number of VLANs that starts triggering the problem or whether this number varies between trials. Also, do you get that error if you are running only the FEA. I.e., configure only the "interfaces" section without configuring/running the MFEA, IGMP, FIB2MRIB and PIM-SM. >From the log messages below it appears that the FEA has decided that the XRL finder is down, hence the FEA exits on its own: [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211 Reply timed out [ 2006/08/28 20:03:44 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 CLI +116 xrl_cli_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... The included information is not sufficient to point the reason why the FEA has decided that the XRL finder is down. You could try to set the XRLTRACE environmenta variable before running XORP. It will enable printing all XRL exchange information, so this might help finding if something has stalled. E.g. you could do the following in csh/tcsh (note that it doesn't matter what value you use to set XRLTRACE, as long as it is set): setenv XRLTRACE yes script ./xorp_rtrmgr -b my_config.boot exit The log file with all the output is in file "typescript". Pavlin > Thanks for any help in this regard. > > Regards , > Ramu.K > > Detailed error LOG > [ 2006/08/28 20:03:00 INFO xorp_rtrmgr:6323 RTRMGR +240 master_conf_tree.cc > execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, > pimsm4 > [ 2006/08/28 20:03:01 INFO xorp_rtrmgr:6323 RTRMGR +99 module_manager.cc > execute ] Executing module: interfaces (fea/xorp_fea) > [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] MFEA enabled > [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI enabled > [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI started > [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] MFEA enabled > [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI enabled > [ 2006/08/28 20:03:01 INFO xorp_fea MFEA ] CLI started > [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh > dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh > dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh > dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh > dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh > dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2006/08/28 20:03:33 ERROR xorp_rtrmgr:6323 FINDER +85 finder_xrl_queue.hh > dispatch_cb ] Sent xrl got response 211 Reply timed out > [ 2006/08/28 20:03:44 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 CLI +116 xrl_cli_node.cc > finder_disconnect_event ] Finder disconnect event. Exiting immediately... > [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 LIBXORP +238 > selector.ccremove_ioevent_cb ] Attempting to remove fd = -1 that is > outside range of > file descriptors 0..73 > [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 MFEA +192 xrl_mfea_node.cc > finder_disconnect_event ] Finder disconnect event. Exiting immediately... > [ 2006/08/28 20:03:44 ERROR xorp_fea:6324 MFEA +192 xrl_mfea_node.cc > finder_disconnect_event ] Finder disconnect event. Exiting immediately... > [ 2006/08/28 20:03:45 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:46 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:47 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:48 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:49 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:50 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:51 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:52 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:53 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:54 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:55 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:56 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:57 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:58 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:03:59 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:00 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:01 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:02 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:03 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:04 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:05 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:06 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:07 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:08 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:09 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:10 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:11 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:12 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:13 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:14 WARNING xorp_rtrmgr:6323 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed > Target "fea" does not exist or is not enabled. > [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +1998 task.cc task_fail > ] Shutting down fatally wounded process (interfaces) > [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +174 module_manager.cc > terminate ] Terminating module: interfaces > [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +197 module_manager.cc > terminate ] Killing module: interfaces > [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +671 > master_conf_tree.cc commit_pass2_done ] Commit failed: Reconfig of process > interfaces caused process to fail. > [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +252 > master_conf_tree.cc config_done ] Configuration failed: Reconfig of process > interfaces caused process to fail. > [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +2228 task.cc run_task ] > No more tasks to run > [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +174 module_manager.cc > terminate ] Terminating module: interfaces > [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +197 module_manager.cc > terminate ] Killing module: interfaces > [ 2006/08/28 20:04:14 ERROR xorp_rtrmgr:6323 RTRMGR +747 module_manager.cc > done_cb ] Command "/root/xorp-1.2/fea/xorp_fea": terminated with signal 15. > [ 2006/08/28 20:04:14 INFO xorp_rtrmgr:6323 RTRMGR +285 module_manager.cc > module_exited ] Module killed during shutdown: interfaces > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From ramu.avula at gmail.com Wed Aug 30 07:44:42 2006 From: ramu.avula at gmail.com (Ramu k) Date: Wed, 30 Aug 2006 20:14:42 +0530 Subject: [Xorp-users] 211 Reply timed out error Message-ID: Hi, >I presume it is working for 50 VLAN interfaces, based on the >information you sent to the list almost 2 months ago (see the thread >with Subject "Too many open files in system"). 1. yes Xorp working fine for 98 VLANS after this even if add a single interface also it comes out >Also, do you get that error if you are running only the FEA. I.e., >configure only the "interfaces" section without configuring/running >the MFEA, IGMP, FIB2MRIB and PIM-SM. 2. yes I am getting the same error by configuring only the "interfaces" and running XORP >You could try to set the XRLTRACE environmenta variable before >running XORP. It will enable printing all XRL exchange information, >so this might help finding if something has stalled. E.g. you could >do the following in csh/tcsh (note that it doesn't matter what value >you use to set XRLTRACE, as long as it is set): I exported XRLTRACE=1 (i am using bash shell)than run XORP It did not create any log file as you specified but printed lot of info messages to the console. I copied all those messages and attached that file with this mail. Some Error messages. [ 2006/08/30 11:07:29 ERROR xorp_rtrmgr:2546 RTRMGR +1998 task.cc task_fail ] Shutting down fatally wounded process (interfaces) [ 2006/08/30 11:07:29 INFO xorp_rtrmgr:2546 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/08/30 11:07:29 INFO xorp_rtrmgr:2546 RTRMGR +197 module_manager.cc terminate ] Killing module: interfaces [ 2006/08/30 11:07:29 ERROR xorp_rtrmgr:2546 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: Reconfig of process interfaces caused process to fail. [ 2006/08/30 11:07:29 ERROR xorp_rtrmgr:2546 RTRMGR +252 master_conf_tree.cc config_done ] Configuration failed: Reconfig of process interfaces caused process to fail. [ 2006/08/30 11:07:29 INFO xorp_rtrmgr:2546 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/08/30 11:07:29 INFO xorp_rtrmgr:2546 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/08/30 11:07:29 INFO xorp_rtrmgr:2546 RTRMGR +197 module_manager.cc terminate ] Killing module: interfaces [ 2006/08/30 11:07:29 ERROR xorp_rtrmgr:2546 RTRMGR +747 module_manager.cc done_cb ] Command "/root/xorp-1.2/fea/xorp_fea": terminated with signal 15. [ 2006/08/30 11:07:29 INFO xorp_rtrmgr:2546 RTRMGR +285 module_manager.cc module_exited ] Module killed during shutdown: interfaces Thanks Pavlin for your help. Regards, Ramu.K -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060830/b2cc4251/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: XORP_log.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060830/b2cc4251/attachment-0001.txt From pavlin at icir.org Wed Aug 30 10:20:05 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 30 Aug 2006 10:20:05 -0700 Subject: [Xorp-users] 211 Reply timed out error In-Reply-To: Message from "Ramu k" of "Wed, 30 Aug 2006 20:14:42 +0530." Message-ID: <200608301720.k7UHK5of051840@possum.icir.org> > >I presume it is working for 50 VLAN interfaces, based on the > >information you sent to the list almost 2 months ago (see the thread > >with Subject "Too many open files in system"). > > 1. yes Xorp working fine for 98 VLANS after this even > if add a single interface also it comes out > > >Also, do you get that error if you are running only the FEA. I.e., > >configure only the "interfaces" section without configuring/running > >the MFEA, IGMP, FIB2MRIB and PIM-SM. > > 2. yes I am getting the same error by configuring only the "interfaces" > and running XORP > > > >You could try to set the XRLTRACE environmenta variable before > >running XORP. It will enable printing all XRL exchange information, > >so this might help finding if something has stalled. E.g. you could > >do the following in csh/tcsh (note that it doesn't matter what value > >you use to set XRLTRACE, as long as it is set): > > I exported XRLTRACE=1 (i am using bash shell)than run XORP It did not create > any log file > as you specified but printed lot of info messages to the console. > I copied all those messages and attached that file with this mail. Thank you for the info. My best guess so far is that it takes too long for the FEA to process all the interface-related configuration, and this triggers the XRL-reated timeouts. The processing is transaction-based and is suppose to be atomic. If it takes long time to complete it, the FEA may stay too long out of the eventloop, and all the XRL-related message exchanges will timeout. Could you send me the script you use to configure 100+ vlans (before starting XORP), and a copy of your "interfaces" XORP configuration file, so I can try to reproduce the problem. Thanks, Pavlin From pavlin at icir.org Wed Aug 30 14:31:21 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 30 Aug 2006 14:31:21 -0700 Subject: [Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop In-Reply-To: Message from "A.H.T" of "Fri, 25 Aug 2006 14:53:05 +0900." <4250f3610608242253r72cafd66g3cc3d55181432e08@mail.gmail.com> Message-ID: <200608302131.k7ULVLWj053860@possum.icir.org> > > Interesting. Could you send me the "route add/change/delete" commands > > how to replicate the problem. > > I added debugging code in routing_socket_utils.cc to show the netmask value. > > I used route add command to add AAAA:BBBB:fad:dead:bee8::/77 prefix > route. After that, zebra deleted AAAA:BBBB:10a::/64 route, but the > routing socket sends a netmask with masklen /77, which I believe is > what's left from my route add command. > > %route -n add -inet6 AAAA:BBBB:fad:dead:bee8:: -prefixlen 77 > fe80::2e0:81ff:fe02:fa52%em0 > add net AAAA:BBBB:fad:dead:bee8::: gateway fe80::2e0:81ff:fe02:fa52%em0 > > [ 2006/08/25 10:40:44 ERROR xorp_fea:18632 FEA +512 > routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 1 prefix > AAAA:BBBB:fad:dead:bee8:: mask ffff:ffff:ffff:ffff:fff8:0:603:600 > masklen 77 nexthop fe80::2e0:81ff:fe02:fa52 > [ 2006/08/25 10:44:03 ERROR xorp_fea:18632 FEA +512 > routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 2 prefix > AAAA:BBBB:10a:: mask :: masklen 77 nexthop fe80::2e0:81ff:fe02:fa52 > [ 2006/08/25 10:44:03 WARNING xorp_fib2mrib XrlFib2mribTarget ] > Handling method for fea_fib_client/0.1/delete_route6 failed: > XrlCmdError 102 Command failed Cannot delete route for > AAAA:BBBB:10a::/77: no such route > [ 2006/08/25 10:44:03 ERROR xorp_fea:18632 FEA +550 xrl_fti.cc > send_fib_client_route_change_cb ] Error sending route change to > fib2mrib: 102 Command failed Cannot delete route for > AAAA:BBBB:10a::/77: no such route > [ 2006/08/25 10:44:04 ERROR xorp_fea:18632 FEA +512 > routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 1 prefix > AAAA:BBBB:10a:: mask :: masklen 64 nexthop fe80::2e0:81ff:fe02:fa52 > > So based on this observation, it seems that the kernel only gives good > netmask value in n * 32bits boundary. After some investigation, your observation seems correct, though I haven't tried to find/confirm the exact boundary (i.e., whether it is 8 bit or 32 bit). Sometimes the "struct sockaddr *" pointer to the netmask data might not contain the whole mask (i.e., the octets with zero at the end). Hence, we need to copy the mask to a "sockaddr_in6" storage that has been zeroed in advance, and then calculate the network mask. This solution is derived from the FreeBSD-6.1 route(8) source code (inside file route.c, function routename()). I just committed a fix to CVS: Revision Changes Path 1.36 +7 -3; commitid: 17c1944f600ac7ea6; xorp/fea/routing_socket_utils.cc Please let me know if you still have the masklen problem. Thanks, Pavlin