[Xorp-users] Announcing XORP Release Candidate 1.2
Atanu Ghosh
atanu@ICSI.Berkeley.EDU
Wed, 22 Feb 2006 20:01:13 -0800
On behalf of the entire XORP team, I'm delighted to announce the XORP
1.2 Release Candidate, which is now available from <http://www.xorp.org>.
Once the release candidate has proven to be stable, the actual 1.2
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.3 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.2-RC (2006/02/22)
=========================
ALL:
[Note: this is XORP-1.2-RC release candidate and not all documentation
is up to date. Also, the list below with the changes since the XORP-1.1
release is incomplete.]
- Many improvements, bug fixes and cleanup.
- The third-party ospfd implementation is replaced with a new
OSPF implementation developed from scratch.
CONFIGURATION:
- Addition of new interface related configuration statement:
* restore-original-config-on-shutdown: <bool>
This optional statement is used to enable the restoring of the
original network interface information on shutdown.
- Addition of new PIM-SM related configuration statements:
* enable-ip-router-alert-option-check: <bool>
This optional statement is used to enable the IP Router Alert option
check per virtual interface.
* cand-bsr-by-vif-addr: <IPv4 | IPv6>
and
* cand-rp-by-vif-addr: <IPv4 | IPv6>
Those optional statements are used together with cand-bsr-by-vif-name
and cand-rp-by-vif-name respectively to specify the particular
IP address on the configured vif. If they are omitted, a domain-wide
address (if exists) that belongs to that interface is chosen by the
router itself.
* hello-period: <u32>
This optional statement is used to configure the PIM Hello messages
period (in seconds).
* hello-triggered-delay: <u32>
This optional statement is used to configure the randomized triggered
delay of the PIM Hello messages (in seconds).
- Addition of new MLD/IGMP related configuration statements:
* version: <u32>
This optional statement is used to configure the MLD/IGMP
protocol version per virtual interface.
* enable-ip-router-alert-option-check: <bool>
This optional statement is used to enable the IP Router Alert option
check per virtual interface.
* query-interval: <u32>
This optional statement is used to specify (per virtual interface)
the interval between general queries.
* query-last-member-interval: <u32>
This optional statement is used to specify (per virtual interface)
the maximum response time inserted into group-specific queries sent
in response to leave group messages.
* query-response-interval: <u32>
This optional statement is used to specify (per virtual interface)
the maximum response time inserted into the periodic general queries.
* robust-count: <u32>
This optional statement is used to specify (per virtual interface)
the robustness variable count that allows tuning for the expected
packet loss on a subnet.
- Addition of support for user environmental variables CFLAGS_END and
CXXFLAGS_END. Those variables can be used to specify the compiler
flags (for the C and C++ compiler respectively) that must be after
all other flags.
LIBXORP:
- Various improvements in the RunCommand implementation.
LIBXIPC:
- No significant changes.
LIBFEACLIENT:
- No significant changes.
XRL:
- No significant changes.
RTRMGR:
- Generalization of the %mandatory keyword syntax so now it can
be used to specify any node or variable (multi-value nodes excluded)
in the configuration tree. Previously it could be used to specify
only configuration child nodes or variables.
- Addition of support for read-only, permanent and user-hidden nodes
(specified respectively by the new %read-only, %permanent and
%user-hidden template commands).
- Modification of the %allow and %allow-range semantics so a help string
can be supplied for each allowed value or range.
- Removal of the mechanism for specifying the hook for saving
a configuration file (the "-s <app>" command-line argument).
The mechanism is broken and is superseded by the rtrmgr template
support for running external programs.
- Various other improvements and bug fixes.
XORPSH:
- Addition of support to run xorpsh in non-interactive mode.
- Modification of the configurational mode "show" command
so now it displays parameters only if their value is not
same as the default value.
- Addition of command "show -all" that shows the complete configuration
including the parameters with default values.
- Modification to the "show" command output: in configuration mode
all deleted (and uncommitted) entries are prefixed with "-".
- Modification of the default operational and configuration mode
prompts to "user@hostname> " and "user@hostname# " respectively.
- Addition of support to modify the operational and configuration
mode prompts by environmental variables
XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION
respectively.
- Addition of support for command-line completion for allowed values.
- Various other improvements and bug fixes.
POLICY:
- Several bug fixes.
FEA/MFEA:
- Addition of RawSocket{4,6} generic abstraction that is not
multicast-specific.
RIB:
- Addition of support for displaying the routing tables in brief,
detailed and terse format. The default format is "brief".
RIP:
- The syntax for configuring the authentication mechanism has changed:
OLD:
authentication {
type: "plaintext"
password: "FOO"
}
OR
authentication {
type: "md5"
password: "FOO"
}
NEW:
authentication {
simple-password: "FOO"
}
OR
authentication {
md5 1 { /* KeyID: [0, 255] */
password: "FOO"
start-time: "YYYY-MM-DD.HH:MM"
end-time: "YYYY-MM-DD.HH:MM"
}
}
- Several bug fixes.
OSPF:
- Initial implementation of OSPF that replaces the third-party ospfd.
BGP:
- The network4/network6 directives have been deprecated.
If you wish to inject static routes into BGP, you must now add
these routes to the static_routes protocol block, and then configure
the policy engine to redistribute them to BGP.
- Proper support for policy filters.
- Addition of support for route flap damping.
- Addition of support for route aggregation.
- Addition of support for route reflection.
- Addition of support for confederations.
- Bug fix to correctly handle connection collisions.
- Addition of default support for NO_EXPORT, NO_ADVERTISE, and
NO_EXPORT_SUBCONFED well-known communities.
- Addition of the capability to reconfigure a peering (e.g., from IBGP to
EBGP) which requires re-configuring the default filters.
- Numerous bug fixes that should greatly improve stability.
STATIC_ROUTES:
- Several bug fixes.
MLD/IGMP:
- No significant changes.
PIM-SM:
- Updated to support the lastest PIM-SM specification
(draft-ietf-pim-sm-v2-new-11.{ps,txt}).
- Addition of support to disable the "wrong iif" kernel upcall on
interfaces we don't need to monitor.
- Bug fix related to the handling of the deleted MRIB entries.
- Bug fix related to transmitting AssertCancel message when
a PIM configured interface is gracefully shutdown.
FIB2MRIB:
- No significant changes.
CLI:
- Various improvements and 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.
- 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:
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
- 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
(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 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 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
- 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 we have 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>
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 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.