[Xorp-hackers] Announcing XORP Release Candidate 1.3

Eddie Kohler kohler at cs.ucla.edu
Wed Jul 19 13:53:51 PDT 2006


Very cool, all!

Eddie


Atanu Ghosh wrote:
> On behalf of the entire XORP team, I'm delighted to announce the XORP
> 1.3 Release Candidate, which is now available from <http://www.xorp.org>.
> 
> Once the release candidate has proven to be stable, the actual 1.3
> 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.
> 
> 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 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 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 and errata are included below.
> 
> ------------------------------------------------------------------
> 		XORP RELEASE NOTES
> 
> Release 1.3-RC (2006/07/19)
> =========================
>   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-3]. 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.
> 
>   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:
>     - No significant changes.
> 
>   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.
> 
>     - The following compiler is known to be buggy, and should not be used
>       to compile XORP:
>         gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD]
>       A newer compiler such as the following should be used instead:
>         gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD]
> 
>     - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time,
>       the propagation latency for the BGP routes to reach the kernel
>       is increased. We are investigating the problem.
> 
>   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
> 
>     - Using the rtrmgr "-r" command-line option to restart processes
>       that have failed does not work if a process fails while being
>       reconfigured via xorpsh. If that happens, the rtrmgr itself may
>       coredump. Therefore, using the "-r" command-line option is not
>       recommended! Also, note that a process that has been killed by
>       SIGTERM or SIGKILL will not be restarted (this is a feature rather
>       than a bug). Ideally, we want to monitor the processes status
>       using the finder rather than the forked children process status,
>       therefore in the future when we have a more robust implementation
>       the "-r" switch will be removed and will be enabled by default.
> 
>   XORPSH:
>     - 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
> 
>   FEA/MFEA:
>     - 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:
>         ...
> 
>       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, but it appears the problem may have been
>       fixed for more recent Linux kernel versions:
> 
>         https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697
> 
>     - On Linux with kernel older than linux-2.6.15-rc7 there is a
>       kernel bug that prevents the FEA to receive netlink(7) notifications
>       about added/deleted IPv6 network addresses and routes:
> 
>         http://www.uwsg.indiana.edu/hypermail/linux/kernel/0512.2/2121.html
> 
>       Typically, this could be an issue only if someone is running
>       IPv6 PIM-SM on Linux, and only if the unicast routes may be modified
>       while XORP is running. In that case the fix would be to replace
>       "RTMGRP_IPV6_IFADDR" with "(RTMGRP_IPV6_IFADDR >> 1)" inside
>       fea/ifconfig_observer_netlink.cc, and to replace "RTMGRP_IPV6_ROUTE"
>       with "(RTMGRP_IPV6_ROUTE >> 1)" inside
>       fticonfig_entry_observer_netlink.cc and
>       fticonfig_table_observer_netlink.cc.
> 
>     - On Linux, adding and deleting multiple IPv4 addresses per interface
>       may trigger an error: typically, if the primary IPv4 address
>       is deleted, the kernel automatically deletes all secondary IPv4
>       addresses on that interface. In Linux kernel 2.6.12 and later,
>       enabling the new sysctl net.ipv4.conf.all.promote_secondaries
>       (or one of the interface specific variants) can be used to
>       automatically promote one of the secondary addresses to become
>       the new primary address.
> 
>     - The mechanism for tracking the network interface link status
>       may not work for the following OS-es because the kernel for those
>       systems does not provide a mechanism for asynchronous notification
>       of userland programs when the link status changes: FreeBSD-5.2 and
>       earlier and MacOS X (note: if the Windows kernel supports this
>       feature, it is not used yet in XORP). Though, for those systems
>       the link status should be read properly on startup.
> 
>   RIB:
>     - In some rare cases, the RIB may fail to delete an existing route:
> 
>         http://www.xorp.org/bugzilla/show_bug.cgi?id=62
> 
>       We are aware of the issue and will attempt to fix it in the
>       future.
> 
>   RIP:
>     - No known issues.
> 
>   OSPF:
>     - 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
> 
>   BGP:
>     - 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 in the
>       future.
> 
>     - The BGP configuration mandates that an IPv4 nexthop must be
>       supplied. Unfortunately it is necessary to provide an IPv4 nexthop
>       even for an IPv6 only peering. Even more unfortunately it is not
>       possible to force the IPv6 nexthop.
> 
>     - It is *essential* for an IPv6 peering that an IPv6 nexthop is
>       provided. Unfortunately the configuration does not enforce this
>       requrement. This will be fixed in the future.
> 
>   STATIC_ROUTES:
>     - No known issues.
>       
>   MLD/IGMP:
>     - If MLD/IGMP is started on Linux with a relatively large number of
>       interfaces (e.g., on the order of 10), 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
> 
>     - 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
> 
>     - Currently, the PIM-SM implementation does not support unnumbered
>       point-to-point links. Furthermore, even on numbered point-to-point
>       links the next-hop information in the routing entries should use
>       an IP address instead of an interface name. For example,
>       if there is a GRE tunnel on Linux and if we want to add a route
>       that uses that tunnel, we should use a command like:
> 
>         route add -net <target> gw <IP address of other side of GRE tunnel>
> 
>       instead of:
> 
>         route add -net <target> <GRE interface name>
> 
>     - If PIM-SM is configured to run over a large number of interfaces
>       (e.g., more than 31 VLANs), it might fail with the following error:
> 
>       [ 2006/07/04 11:56:23  ERROR xorp_fea:28353 MFEA +967 mfea_mrouter.cc
>       add_multicast_vif ]
>       setsockopt(MRT_ADD_VIF, vif eth0.4) failed: Too many open files in system
> 
>       The reason for that error is that by default majority of the UNIX
>       kernels cannot support more than 32 interfaces enabled for multicast
>       forwarding (one interface is always used as the internal PIM Register
>       virtual interface).
> 
>       The solution is to increase the MAXVIFS limit in the kernel
>       (typically defined in the "netinet/ip_mroute.h" (BSD) or the
>       "include/linux/mroute.h" (Linux) kernel file), and recompile the
>       kernel. It should be increased also in the corresponding system
>       header file as well: <netinet/ip_mroute.h> or <linux/mroute.h>.
>       After that XORP should be recompiled to take into account the
>       MAXVIFS increase. If modifying the system header files is not
>       acceptable, then the following should be added toward the end of
>       file "xorp/mrt/max_vifs.h" before recompiling XORP:
> 
>       #undef MAX_VIFS
>       #define MAX_VIFS 50
> 
>   FIB2MRIB:
>     - No known issues.
> 
>   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 the following URL for links to the net-snmp
>       patches that solve the problems:
> 
>         http://www.xorp.org/snmp.html
> 
>     - Version 5.1 of net-snmp requires a simple modification, otherwise
>       XORP will fail to compile.
>       See the following URL for a link to the net-snmp patch that solves
>       the problems:
> 
>          http://www.xorp.org/snmp.html 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



More information about the Xorp-hackers mailing list