From davidj@ICSI.Berkeley.EDU Sat Feb 21 01:48:22 2004 From: davidj@ICSI.Berkeley.EDU (David Johnson) Date: Fri, 20 Feb 2004 17:48:22 -0800 Subject: [Xorp-announce] test3 Message-ID: <16438.47334.858875.439327@sage.ICSI.Berkeley.EDU> test3 From atanu@ICSI.Berkeley.EDU Fri Jul 9 08:08:48 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 09 Jul 2004 00:08:48 -0700 Subject: [Xorp-announce] Announcing XORP Release 1.0 Message-ID: <98501.1089356928@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.0 Release, which is now available from . 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 Release 1.0 (2004/07/08) ========================= 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. - Building with the optimizer ("./configure --enable-optimize") will cause the build to fail. The build fails because some warnings are generated by the compiler and we treat warnings as fatal. This problem was discovered too late to be fixed for this release. 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. - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show mfea interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the MFEA module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358), some of the tests may fail (with or without an error message), but no coredump image. Some of those failures can be contributed to a kernel problem. E.g., running "dmesg can show kernel "Oops" messages like: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 02235532 *pde = 00000000 Oops: 0000 [#15] CPU: 0 EIP: 0060:[<02235532>] Not tainted EFLAGS: 00010202 (2.6.5-1.358) EIP is at __dev_get_by_index+0x14/0x2b eax: 022db854 ebx: 1ae7aef8 ecx: 00000001 edx: 00000000 esi: 00000000 edi: 00008910 ebp: fee43e9c esp: 1ae7aef0 ds: 007b es: 007b ss: 0068 Process test_finder_eve (pid: 2026, threadinfo=1ae7a000 task=1406d7b0) Stack: 022365c7 00000000 009caffc 009cc780 0969ef28 fee43edc 00000001 009cc780 0969ef28 fee43ed8 00008910 00000000 00008910 fee43e9c 02236e50 fee43e9c 07aa4e00 3530355b 5d303637 00000000 0227a55b 021536b6 022cfa00 00000001 Call Trace: [<022365c7>] dev_ifname+0x30/0x66 [<02236e50>] dev_ioctl+0x83/0x283 [<0227a55b>] unix_create1+0xef/0xf7 [<021536b6>] alloc_inode+0xf9/0x175 [<0227c090>] unix_ioctl+0x72/0x7b [<022301a5>] sock_ioctl+0x268/0x280 [<0223054f>] sys_socket+0x2a/0x3d [<0214ea0e>] sys_ioctl+0x1f2/0x224 Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME) which itself is called by if_indextoname(3). Currently, there is no known solution of the problem except to use a kernel that does not have the problem (at this stage it is not known whether all 2.6 Linux kernels are affected or only specific versions). It seems that a very similar problem has been reported to the Linux kernel developers, but the problem is still unsolved: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 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. - If the RIB bug above (failure to delete an existing route) is triggered by BGP, then the deletion failure error received by BGP from the RIB is considered by BGP as a fatal error. This is not a BGP problem, but a RIB problem that will be fixed after the XORP Release-1.0. 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 - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show igmp interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the MLD/IGMP module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. 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 - On Linux, if the unicast Reverse Path Forwarding information is different from the multicast Reverse Path Forwarding information, the Reverse Path Filtering should be disabled. E.g., as root: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter OR echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter ... Otherwise, the router will ignore packets if they don't arrive on the reverse-path interface. For more information about Reverse Path Filtering see http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show pim interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the PIM-SM module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. - Very late in the release process a problem was found with scheduling the internal PIM-SM tasks for state dependency tracking. The result of it is that if the router is heavy loaded and if it has lots of multicast routing state, then any change that affects many multicast routing entries (e.g., MRIB changes, etc) in some cases may result in incorrect recomputation of the result multicast routing state. This problem will be fixed in the CVS repository right after the XORP Release-1.0. FIB2MRIB: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. CLI: - No known issues. SNMP: - On some versions of Linux, there are some bugs in net-snmp versions 5.0.8 and 5.0.9, which prevent dynamic loading from working. See http://www.xorp.org/snmp.html for links to the net-snmp patches that solve the problems. - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See http://www.xorp.org/snmp.html for a link to the net-snmp patch that solves the problems. ------------------------------------------------------------------