[Xorp-hackers] Announcing XORP Release Candidate 1.4

Atanu Ghosh atanu at ICSI.Berkeley.EDU
Wed Feb 28 13:54:31 PST 2007

On behalf of the entire XORP team, I'm delighted to announce the XORP
1.4 Release Candidate, which is now available from <http://www.xorp.org>.

The major feature of this release is the addition of OSPFv3 (OSPF for IPv6).

Once the release candidate has proven to be stable, the actual 1.4
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.

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

Release notes included below.


Release 1.4-RC (2006/02/28)
    - XORP now builds on DragonFlyBSD-1.8, FreeBSD-6.2, Linux Fedora
      Core6, Linux Debian-3.1 (sarge), NetBSD-3.1 and OpenBSD-4.0.

    - XORP now can be compiled with the Intel C/C++ compiler 9.* on

    - XORP now can be cross-compiled for IA-64, MIPS (Broadcom for
      Linksys WRT54G), PowerPC-603, Sparc64, and XScale processors.

    - Implementation of OSPFv3 (draft-ietf-ospf-ospfv3-update-14.txt).

    - Implementation of floating static routes (i.e., static routes
      for the same prefix with different next hop and metrics).

    - Allow static routes to have "nexthop4" and "nexthop6" policy
      matching conditions in the "from" block.

    - Addition of new FEA configuration statements to retain XORP
      unicast forwarding entries on startup or shutdown:

      fea {
          unicast-forwarding4 {
              forwarding-entries {
                  retain-on-startup: false
                  retain-on-shutdown: false
          unicast-forwarding6 {
              forwarding-entries {
                  retain-on-startup: false
                  retain-on-shutdown: false

      The default value for each statement is false.
      Note that those statements prevent the FEA itself from deleting
      the forwarding entries and does not prevent the RIB or any of the
      unicast routing protocols from deleting the entries on shutdown.

    - The "elements" policy statements for configuring sets of network
      routes have been deprecated:

      policy {
          network4-list foo {
              elements: ","
          network6-list bar {
              elements: "2222::/64,3333::/64"

      The new replacement statement is "network" and can be used to
      specify one element per line:

      policy {
          network4-list foo {
          network6-list bar {
              network 2222::/64
              network 3333::/64

    - The following keywords are supported inside the policy
      configuration when comparing IPv4 or IPv6 network prefixes:
      exact, longer, orlonger, shorter, orshorter, not. For example:

      "network4 exact"     SAME AS "network4 =="
      "network4 longer"    SAME AS "network4 <"
      "network4 orlonger"  SAME AS "network4 <="
      "network4 shorter"   SAME AS "network4 >"
      "network4 orshorter" SAME AS "network4 >="
      "network4 not"       SAME AS "network4 !="

      The original operators are supported as well.

    - A floating static route (also called "qualified" by some router
      vendors) can be added with a configuration like:

      protocols {
          static {
              route {
                  metric: 1
                  qualified-next-hop {
                      metric: 10
              interface-route {
                  next-hop-interface: "rl0"
                  next-hop-vif: "rl0"
                  metric: 1
                  qualified-next-hop-interface rl1 {
                      qualified-next-hop-vif rl1 {
                          metric: 10

    - The XORP scheduler now has support for priority-based tasks.

    - No significant changes.

    - No significant changes.

    - No significant changes.

    - Bug fix in the semantics of the rtrmgr template %activate keyword.

    - No significant changes.

    - Bug fix related to creating export policies that match protocol's
      its own routes (e.g., a policy that modifies the BGP routes
      exported to its peers).

    - Various other bug fixes.

    - Fix the routing socket based mechanism (used by BSD-derived
      systems) for obtaining the interface name (toward the destination)
      for a routing entry.

    - Apply a performance improvement when configuring a large number of
      interfaces/VIFs, each of them with the "default-system-config"
      configuration statement.

    - Bug fix related to atomically modifying the IP address of an interface.

    - Bug fix related to (not) installing redundant host-specific
      entries for the other side of a point-to-point interface if the
      netmask for the interface covers the host-specific entry.

    - No significant changes.

    - OSPFv3 is now available.

    - The OSPFv3 protocol requires that link-local addresses are used,
      therefore it is necessary to configure a link-local address for
      each interface, this restriction will be removed in the future.

    - The OSPFv3 configuration allows multiple instances to be configured
      however only one instance will be created.

    - For OSPFv3 only one global address can be set on an interface,
      multiple addresses will be allowed in the final release. Please
      note that the configuration will change when multiple addresses
      are supported.

    - The OSPFv3 specification requires that unknown LSAs should be
      processed, currently unknown LSAs are incorrectly considered an
      error. Unknown LSAs will be handled in the final release.

    - OSPFv3 has support for virtual links but adjacencies are not
      always correctly formed.
    - Bug fix related to the processing of previously generated LSAs
      on startup has been fixed. Restarting a router that was the
      designated router could exhibit this problem.
    - Bug fix on a broadcast interface if the router was not the
      designated router then the nexthop was incorrectly
      unconditionally set to the designated router; introducing an
      unnecessary extra hop.

    - BGP has taken advantage of the priority-based tasks in the XORP
      scheduler and background tasks are run at a low priority;
      leading to improved performance.

    - Bug fix related to declaring some of the policy matching
      conditions in the "from" block.

    - Bug fix related to atomically modifying the IP address of an

    - Bug fix related to ignoring protocol messages that are not
      recognized by the configured protocol version on an interface.

    - Ignore control messages if the source address is not directly

    - Don't send the periodic Group-Specific or Group-and-Source-Specific
      Queries for entries that are in IGMPv1 mode.

    - Bug fix related to atomically modifying the IP address of an

    - The PIM-SM control messages do not include the IP Router Alert
      option anymore, because it has been included from the newer
      revisions of the PIM-SM protocol specification (RFC 4601 and

    - Don't send PIM Hello message with DR Priority of 0 when shutting
      down an interface, because this is not part of the protocol

    - Bug fix related to updating the interface and vif name of a
      forwarding entry received from the FEA.

    - Performance improvement if the CLI is processing a large amount
      of data. E.g., if xorpsh is used in a pipe like:

      cat commands.txt | xorpsh

    - Bug fix with the snmpd arguments when sampling whether snmpd
      can start and its version is >= 5.2.


More information about the Xorp-hackers mailing list