[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