From orion@icir.org Thu Jun 10 17:27:47 2004 From: orion@icir.org (Orion Hodson) Date: Thu, 10 Jun 2004 09:27:47 -0700 Subject: [Xorp-hackers] HEADS UP - ospfd relocation Message-ID: <1C28385A-BAFB-11D8-AAA6-000A95DA7C7A@icir.org> ospfd has just been moved from the top-level of the XORP source tree to contrib. For existing checked out copies of XORP, you should re-run configure after your next cvs update to generate the appropriate Makefile updates. The motivation for the move is that we'd like to isolate source code covered by different licensing terms, ospfd is under the GPL, whilst most of XORP is under a BSD-style licence. And after the 1.0 release, we'd like to kick off a combined IPv4 and IPv6 capable ospf implementation. Kind Regards Orion ------------------------------------------------------------------------ Orion Hodson, Researcher XORP Router Project http://www.xorp.org/ International Computer Science Institute http://www.icsi.berkeley.edu/ 1947 Center St, Berkeley, CA94704 Tel (510) 666-2927 Fax (510) 666-2956 ------------------------------------------------------------------------ From bms@spc.org Thu Jun 10 18:16:43 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 10 Jun 2004 18:16:43 +0100 Subject: [Xorp-hackers] Grabbing complete rcs files (CVSup vs anoncvs checkouts) In-Reply-To: <1C28385A-BAFB-11D8-AAA6-000A95DA7C7A@icir.org> References: <1C28385A-BAFB-11D8-AAA6-000A95DA7C7A@icir.org> Message-ID: <20040610171643.GD25241@empiric.dek.spc.org> On Thu, Jun 10, 2004 at 09:27:47AM -0700, Orion Hodson wrote: > ospfd has just been moved from the top-level of the XORP source tree to > contrib. For existing checked out copies of XORP, you should re-run > configure after your next cvs update to generate the appropriate > Makefile updates. Excellent stuff. I am tracking XORP HEAD vis anoncvs at the moment; Can I get at the RCS files themselves? CVSup if possible, would be great, as I'd like to be able to build and diff without nuking the build directory. Regards, BMS From orion@icir.org Thu Jun 10 18:34:37 2004 From: orion@icir.org (Orion Hodson) Date: Thu, 10 Jun 2004 10:34:37 -0700 Subject: [Xorp-hackers] Re: Grabbing complete rcs files (CVSup vs anoncvs checkouts) In-Reply-To: <20040610171643.GD25241@empiric.dek.spc.org> References: <1C28385A-BAFB-11D8-AAA6-000A95DA7C7A@icir.org> <20040610171643.GD25241@empiric.dek.spc.org> Message-ID: <71F5750F-BB04-11D8-AAA6-000A95DA7C7A@icir.org> On Jun 10, 2004, at 10:16, Bruce M Simpson wrote: > I am tracking XORP HEAD vis anoncvs at the moment; Can I get at the RCS > files themselves? CVSup if possible, would be great, as I'd like to be > able to build and diff without nuking the build directory. The anonymous cvs is updated every 8 minutes so it shouldn't take too long for the update to ripple through. We don't have any way of exposing the RCS files just now, though we could set up cvsupd when there are some more cycles or cycle processors available. Orion ------------------------------------------------------------------------ Orion Hodson, Researcher XORP Router Project http://www.xorp.org/ International Computer Science Institute http://www.icsi.berkeley.edu/ 1947 Center St, Berkeley, CA94704 Tel (510) 666-2927 Fax (510) 666-2956 ------------------------------------------------------------------------ From atanu@ICSI.Berkeley.EDU Tue Jun 15 23:48:34 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 15 Jun 2004 15:48:34 -0700 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.0 Message-ID: <98317.1087339714@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.0 Release Candidate, which is now available from . Once the release candidate has proven to be stable, the actual 1.0 release will be prepared. This is planned to occur in the next two weeks. In the intervening period we will be fixing minor problems and updating the documentation. The XORP router is now totally configurable through the XORP shell (xorpsh). A quick start guide is available from . Please note that a XORP Live CD is also available. This is a bootable CD that allows you to experiment with XORP without having to build or install it. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.1 release; these are documented in the errata section below. 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@xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback@xorp.org. - The XORP Team P.S. Release notes and errata are included below. ------------------------------------------------------------------ XORP RELEASE NOTES This file contains XORP release notes (most recent releases first). Release 1.0RC (2004/06/15) ========================= ALL: - All the routing processes can now be started and configured via the RTRMGR/XORPSH. LIBXORP: - Addition of support for safe callbacks (e.g., if an object is destroyed, all callbacks that refer to that object are invalidated). LIBXIPC: - Addition of support for event notification if the status of a target changes. LIBFEACLIENT: - Few bug fixes. XRL: - No significant changes. RTRMGR: - Addition of new command-line option "-v" to print verbose information. - Removal of command-line option "-d" that prints default information, because the same information is printed with the "-h" flag. - Addition of support for explicit configuration of the XRL target name of a module. - Addition of support for %help command in the rtrmgr template files. - Addition of support for new methods per module: "startup_method" and "shutdown_method". - Numerous other improvements and bug fixes. XORPSH: - Addition of new command-line option "-v" to print verbose information. - Removal of command-line option "-d" that prints default information, because the same information is printed with the "-h" flag. - Addition of support for help string in the xorpsh operational commands template files. - Addition of support for positional arguments in the xorpsh operational commands template files. - Addition of support to interrupt an operational command. Now if a command is interrupted from the command line by typing Ctrl-C, then the executed binary command itself (and its forked children, if any) is killed. - Numerous other improvements and bug fixes. FEA/MFEA: - Addition of support for propagating the Forwarding Information Base from the underlying system to clients interested in that information. - Addition of support for opening TCP or UDP sockets via the FEA. - Modification to the MFEA to use "libfeaclient" to obtain the interface information from the FEA. - Numerious bug fixes. RIB: - Addition of support for redistributing routes between two internal tables. - Addition of support for obtaining routes directly from some of the internal tables. - Modification to the RIB to use "libfeaclient" to obtain the interface information from the FEA. - Modification to the RIB to use the new RedistTable to propagate the final routes to the FEA and anyone else interested (e.g., PIM-SM). - Few bug fixes. RIP: - Packet forwarding and reception via FEA written for RIPv2 and RIPng. RIPv2 should be usable. BGP: - IPv6 has now been tested with peerings to the 6Bone; unicast and multicast SAFIs. - Route origination is now possible from BGP. - The memory leaks from the previous release have been found and fixed. STATIC_ROUTES: - This is a new module for configuring static routes to the unicast or multicast RIB. MLD/IGMP: - During startup, a primary address is selected per configured interface, and this primary address should be the link-local unicast address of that interface. - New CLI commands: "show igmp interface address" and "show mld interface address" - Resend some of the XRLs (e.g., those who do not carry soft-state such as protocol control messages) if there is an error. - Few bug fixes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-09.{ps,txt}). - Addition of support for "alternative subnet" configuration such that non-local senders appear as senders connected to the same subnet. It is needed as a work-around solution when there are uni-directional interfaces for sending and receiving traffic (e.g., satellite links). - During startup, a primary address and a domain-wide address are selected per configured interface. The primary address should be the link-local unicast address of that interface, and the domain-wide address should be a domain-wide reachable unicast address. - Resend some of the XRLs (e.g., those who do not carry soft-state such as protocol control messages) if there is an error. - Several bug fixes. FIB2MRIB: - This is a new module for propagating the unicast forwarding information obtained from the underlying system via the FEA to the multicast RIB. CLI: - Addition of support to propagate command interruption (e.g., Ctrl-C) from the CLI to the object that handles the command processing by calling a pre-defined callback. - During startup, if the input is a terminal (e.g., xorpsh), then read the terminal size instead of using the default values. - A bug fix related to the CLI paging output: now it can handle properly lines that are longer than the width of the CLI output terminal. - Several other bug fixes. SNMP: - No significant changes. ------------------------------------------------------------------ XORP ERRATA ALL: - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines. The simplest work-around is to rerun gmake or not to use the -j flag. - Overwriting the default installation prefix by running "./configure --prefix=/path/to/xorp" currently does not work. This will be fixed for XORP Release 1.0. - Some of the design documentation in ${XORP}/docs/ hasn't been updated for this release candidate. This will be fixed for XORP Release 1.0. LIBXORP: - No known issues. LIBXIPC: - No known issues. LIBFEACLIENT: - No known issues. XRL: - No known issues. RTRMGR: - There are several known issues, but none of them is considered critical. The list of known issues is available from http://www.xorp.org/bugzilla/query.cgi XORPSH: - A problem was noticed very late in the release process; rather than delay the release we have choosen to document the problem. The xorpsh provides the command line to the XORP router. The router configuration is structured as a tree, for instance configuring a new protocol essentially adds a new node to the tree. Removing a protocol involves deleting a node from the tree. In some cases deleting a node does not remove all the associated state; worse putting the same node back seems to fail in the majority of cases. FEA/MFEA: - On Linux, the following error message may appear during graceful shutdown (if PIM-SM is also running): [ 2004/06/09 14:50:40 ERROR xorp_fea:14359 MFEA +1676 mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (10.10.10.10 224.0.1.20)) failed: Bad file descriptor The error is harmless and can be ignored. RIB: - If an interface address is deleted, the RIB may trigger the following error in the FEA: [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +259 fticonfig_entry_set_rtsock.cc delete_entry ] error writing to routing socket: No such process [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +61 fti_transaction.cc operation_result ] FTI transaction commit failed on DeleteEntry4: net = 172.16.124.0/24 gateway = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +259 This error has no side effects, and can be ignored. - In some rare cases, the RIB may fail to delete an existing route (See http://www.xorp.org/bugzilla/show_bug.cgi?id=62). We are aware of the issue and will attempt to fix it in the near future. RIP: - No known issues. BGP: - Once BGP selects a route it is taking too long to install it in the kernel. - The RIB bug above where deleting an existing route can fail is sometimes triggered by BGP. When BGP receives the deletion failure error from the RIB it considers this to be a fatal error and exits. This problem will be fixed before the XORP 1.0 Release. STATIC_ROUTES: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. MLD/IGMP: - If MLD/IGMP is started with a relatively large number of interfaces (e.g., on the order of 20), then it may fail with the following error: [ 2004/06/14 12:58:56 ERROR test_pim:16548 MFEA +666 mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2 on vif eth8: No buffer space available The solution is to increase the multicast group membership limit. E.g., to increase the value from 20 (the default) to 200, run as a root: echo 200 > /proc/sys/net/ipv4/igmp_max_memberships PIM-SM: - If the kernel does not support PIM-SM, or if PIM-SM is not enabled in the kernel, then running PIM-SM will fail with the following error message: [ 2004/06/12 10:26:41 ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported FIB2MRIB: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. CLI: - No known issues. SNMP: - net-snmp-5.1.* may have problems with some of its header files, hence the XORP SNMP support won't be compiled if those problems exist. Instead, use an earlier net-snmp version from the 5.0.x branch. ------------------------------------------------------------------ From bms@spc.org Wed Jun 16 05:49:02 2004 From: bms@spc.org (Bruce M Simpson) Date: Wed, 16 Jun 2004 05:49:02 +0100 Subject: [Xorp-hackers] FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems Message-ID: <20040616044902.GM26312@empiric.dek.spc.org> Has multicast group membership been an issue with FreeBSD and point-to-point interfaces in any of your testing? I'm trawling through the FreeBSD PRs which I currently own. RIP in particular appears to be something which suffers from this, according to this problem report: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/51927 The Rhyolite.com routed source tries to work around the problem in various ways; if MCAST_PPP_BUG is defined when compiled, it simply doesn't enable multicast for RIPv2 on IFF_POINTOPOINT interfaces. As this applies to XORP: looking at comm_sock_join4() in libcomm/comm_sock.c, no such assumptions are made, it is a simple helper for IP_ADD_MEMBERSHIP, so I imagine this issue may bite. The patch proposed in the PR tries to match on the remote address of a PTP interface if the original ifp lookup fails. This would certainly be the case for an unnumbered interface. NetBSD, on the other hand, allows multicast group memberships to be added by interface index: http://mail-index.netbsd.org/tech-net/2003/10/24/0005.html Further research reveals that this is mandated by RFC 1724 section 3.3 (RIP Version 2 MIB Extension) which mandates the special casing of ip_multicast_if() within the BSD stack where 0.0.0.0/8 is concerned. [After discussion with FreeBSD network junta, I'll commit something for this soon.] Regards, BMS From bms@spc.org Wed Jun 16 06:03:18 2004 From: bms@spc.org (Bruce M Simpson) Date: Wed, 16 Jun 2004 06:03:18 +0100 Subject: [Xorp-hackers] Re: FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: <20040616044902.GM26312@empiric.dek.spc.org> References: <20040616044902.GM26312@empiric.dek.spc.org> Message-ID: <20040616050318.GN26312@empiric.dek.spc.org> On Wed, Jun 16, 2004 at 05:49:02AM +0100, Bruce M Simpson wrote: > NetBSD, on the other hand, allows multicast group memberships to > be added by interface index: ... > [After discussion with FreeBSD network junta, I'll commit something for > this soon.] It might help if I checked if this were actually in HEAD first before I go shooting my mouth off. :-) Been in HEAD since rev 1.127 and was originally merged from KAME by ume@. MFCed since rev 1.99.2.15 (FreeBSD 4.4-RELEASE). Still undocumented. Ok, I'll schedule an update for src/share/man/man4/ip.4. Regards, BMS From pavlin@icir.org Thu Jun 17 01:35:59 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 16 Jun 2004 17:35:59 -0700 Subject: [Xorp-hackers] FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: Message from Bruce M Simpson of "Wed, 16 Jun 2004 05:49:02 BST." <20040616044902.GM26312@empiric.dek.spc.org> Message-ID: <200406170035.i5H0ZxKh002935@possum.icir.org> > Has multicast group membership been an issue with FreeBSD and > point-to-point interfaces in any of your testing? > I'm trawling through the FreeBSD PRs which I currently own. > > RIP in particular appears to be something which suffers from this, > according to this problem report: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/51927 > > The Rhyolite.com routed source tries to work around the problem > in various ways; if MCAST_PPP_BUG is defined when compiled, it > simply doesn't enable multicast for RIPv2 on IFF_POINTOPOINT > interfaces. > > As this applies to XORP: looking at comm_sock_join4() in > libcomm/comm_sock.c, no such assumptions are made, it is a simple > helper for IP_ADD_MEMBERSHIP, so I imagine this issue may bite. Bruce, I think XORP doesn't suffer from that problem for the simple reason that we don't support unnumbered interfaces. I.e., each interface must have a valid IP address, otherwise it won't be used by any of our protocols. Hence, in case of P2P links our IP_ADD_MEMBERSHIP simply uses the local IP address on our side of the P2P link. After all, this is the purpose of field "ip_mreq.imr_interface" (defined in netinet/in.h). I read the above problem report, and one thing it talked about was if several P2P interfaces share the same local IP address. However, I believe this applies only for tunnel interfaces, and only for the "outer" IP addresses of such P2P interfaces; i.e., the "inner" IP addresses would be different. Then, if RIP (or any other protocol) is running on that interface, it would use the inner IP address which is unique, and IP_ADD_MEMBERSHIP with that address would be fine. However, in general, if a P2P interface has no IP address assigned, and if you want your protocol to run over such unnumbered interface, then the protocol itself (RIP, etc) should do the right thing by not attempting to use IP_ADD_MEMBERSHIP on that interface. In other words, I don't see a reason that the kernel needs to be modified, because the problem is not there. Indeed, in general it will be nicer if in case of IPv4 we can use the interface index to specify the interface (similar to IPv6), but woudn't be cleaner to use a separate API rather than hacking the IP address values in the existing API. Pavlin P.S. BTW, I quickly tested the XORP RIP implementation with a tun0 interface created with openvpn, and it seems it can correctly identify that interface and use it. The FEA itself when it reads the interface information from the kernel also can identify properly the inner IP address. > > The patch proposed in the PR tries to match on the remote address > of a PTP interface if the original ifp lookup fails. This would > certainly be the case for an unnumbered interface. > > NetBSD, on the other hand, allows multicast group memberships to > be added by interface index: > http://mail-index.netbsd.org/tech-net/2003/10/24/0005.html > > Further research reveals that this is mandated by RFC 1724 section > 3.3 (RIP Version 2 MIB Extension) which mandates the special casing > of ip_multicast_if() within the BSD stack where 0.0.0.0/8 is concerned. > > [After discussion with FreeBSD network junta, I'll commit something for > this soon.] > > Regards, > BMS > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Thu Jun 17 01:37:22 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 16 Jun 2004 17:37:22 -0700 Subject: [Xorp-hackers] Re: FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: Message from Bruce M Simpson of "Wed, 16 Jun 2004 06:03:18 BST." <20040616050318.GN26312@empiric.dek.spc.org> Message-ID: <200406170037.i5H0bMKh002946@possum.icir.org> > On Wed, Jun 16, 2004 at 05:49:02AM +0100, Bruce M Simpson wrote: > > NetBSD, on the other hand, allows multicast group memberships to > > be added by interface index: > ... > > [After discussion with FreeBSD network junta, I'll commit something for > > this soon.] > > It might help if I checked if this were actually in HEAD first > before I go shooting my mouth off. :-) Been in HEAD since rev 1.127 > and was originally merged from KAME by ume@. BTW, which file is this? :) Pavlin > > MFCed since rev 1.99.2.15 (FreeBSD 4.4-RELEASE). > Still undocumented. Ok, I'll schedule an update for src/share/man/man4/ip.4. > > Regards, > BMS > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From bms@spc.org Thu Jun 17 22:30:26 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 17 Jun 2004 22:30:26 +0100 Subject: [Xorp-hackers] Re: FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: <200406170037.i5H0bMKh002946@possum.icir.org> References: <20040616050318.GN26312@empiric.dek.spc.org> <200406170037.i5H0bMKh002946@possum.icir.org> Message-ID: <20040617213026.GG37877@empiric.dek.spc.org> On Wed, Jun 16, 2004 at 05:37:22PM -0700, Pavlin Radoslavov wrote: > > BTW, which file is this? :) Doh. src/sys/netinet/ip_input.c. :-) BMS From pavlin@icir.org Fri Jun 18 00:58:56 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 17 Jun 2004 16:58:56 -0700 Subject: [Xorp-hackers] Re: FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: Message from Bruce M Simpson of "Thu, 17 Jun 2004 22:30:26 BST." <20040617213026.GG37877@empiric.dek.spc.org> Message-ID: <200406172358.i5HNwuKh048609@possum.icir.org> > On Wed, Jun 16, 2004 at 05:37:22PM -0700, Pavlin Radoslavov wrote: > > > > BTW, which file is this? :) > > Doh. src/sys/netinet/ip_input.c. :-) I am confused. I coudn't find anything interesting in the diff between rev. 1.127 (the revision you mentioned in your previous email) and rev 1.126 of ip_input.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c.diff?r1=1.126&r2=1.127 Also, ip_input.c doesn't have revision 1.99.2.15 (another revision number you mentioned in your email). Double-confused... Pavlin From bms@spc.org Fri Jun 18 02:10:01 2004 From: bms@spc.org (Bruce M Simpson) Date: Fri, 18 Jun 2004 02:10:01 +0100 Subject: [Xorp-hackers] Re: FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: <200406172358.i5HNwuKh048609@possum.icir.org> References: <20040617213026.GG37877@empiric.dek.spc.org> <200406172358.i5HNwuKh048609@possum.icir.org> Message-ID: <20040618011001.GC43211@empiric.dek.spc.org> On Thu, Jun 17, 2004 at 04:58:56PM -0700, Pavlin Radoslavov wrote: > > On Wed, Jun 16, 2004 at 05:37:22PM -0700, Pavlin Radoslavov wrote: > > > > > > BTW, which file is this? :) > > > > Doh. src/sys/netinet/ip_input.c. :-) > > I am confused. I coudn't find anything interesting in the diff > between rev. 1.127 (the revision you mentioned in your previous > email) and rev 1.126 of ip_input.c: Ack, sorry, I meant ip_output.c in this case. Been switching between PRs too much! http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.126&r2=1.127 It looks as though cvsweb is having problems at the moment. The log for this change was: ---------------------------- revision 1.127 date: 2001/06/11 18:38:11; author: ume; state: Exp; lines: +1 -1 This is force commit to mention about previous commit. - use 0/8 to specify interface index on multicast get/setsockopt - make sure to nuke m->m_aux pointer for ipsec, on if_output. - pass error from ipsec_setsocket() all the way up. - move ipsec output processing before filtering section. ---------------------------- ...so the RFC 1724 changes are actually part of the KAME sync in rev 1.126. Sorry for the confusion. Regards, BMS From pavlin@icir.org Sat Jun 19 01:57:46 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 18 Jun 2004 17:57:46 -0700 Subject: [Xorp-hackers] Re: FreeBSD: IP_ADD_MEMBERSHIP on IFF_POINTOPOINT problems In-Reply-To: Message from Bruce M Simpson of "Fri, 18 Jun 2004 02:10:01 BST." <20040618011001.GC43211@empiric.dek.spc.org> Message-ID: <200406190057.i5J0vkKh085351@possum.icir.org> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.126&r2=1.127 > > It looks as though cvsweb is having problems at the moment. The log > for this change was: > > ---------------------------- > revision 1.127 > date: 2001/06/11 18:38:11; author: ume; state: Exp; lines: +1 -1 > This is force commit to mention about previous commit. > > - use 0/8 to specify interface index on multicast get/setsockopt > - make sure to nuke m->m_aux pointer for ipsec, on if_output. > - pass error from ipsec_setsocket() all the way up. > - move ipsec output processing before filtering section. > ---------------------------- > > ...so the RFC 1724 changes are actually part of the KAME sync in rev 1.126. Ah, this looks like an ugly hack. Indeed, RFC-1724 is the one that suggests that 0.0.0.0/8 is interpreted as an interface index, but lets not forget that the title of that RFC is "RIP Version 2 MIB Extension". In my opinion, the above interpretation should be limited to MIB-related code only, and should not be propagated to places like the generic multicast code in the kernel. Anyway, this ML is not the right place for such discussion, and what is done is done. After all, you didn't send your email to ask us about opinion whether we like the above solution, but whether XORP has problems on P2P links :) Regards, Pavlin