[Xorp-users] Announcing XORP Release Candidate 1.3
Atanu Ghosh
atanu at ICSI.Berkeley.EDU
Wed Jul 19 12:13:51 PDT 2006
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
More information about the Xorp-users
mailing list