[Xorp-hackers] Release 1.8.3 is almost done, please test

Ray Soucy rps at maine.edu
Thu Mar 17 10:32:21 PDT 2011


I've been out of the loop on CT changes as we are still a 1.6
environment in production.  Now that CT is merged into official I have
a few questions on 1.8.3 vs 1.7 svn.

In 1.7 we saw a lot of work to move to start using Boost.  I see that
in 1.8.3 it's a build option called "enable_boost" that defaults to
False, what's the extent of Boost in 1.8.3?  Is it supported, or are
we moving away from that change? Pros vs. Cons?  Suspect that it was
done to cut down the footprint, but will it be actively maintained
going forward I guess is my real question.

Numbering-wise, I think we might call this release 1.8.0 since 1.8
doesn't exists for XORP (realize it does for CT).  Also the version
reported by xorp needs to be updated (it's still reporting 1.8-CT).

Also think that it would be nice to maintain the same format for
RELEASE_NOTES that was previously used by the XORP project.  The CT
RELEASE_NOTES got a little out of control with the inclusion of the
Git log and style changes.  Here is an example for 1.8.0 (which would
come right before 1.7):

Release 1.8.0  (2011/03/17)
============================
  ALL:
    - XORP-CT branch merged into XORP.
	- New release numbering (1.8.0 vs 1.8) to accomodate more frequent
	  updates.
	- New build options allow for exclusion of XORP modules.
...

Testing looks OK so far in VMs.

Init scripts for XORP is still something thats a little flaky.  I
checked and the xrl sockets are created with the correct permissions
now, which keeps xorpsh happy.

I tried writing a new init script that sends SIGKILL to xorp_rtrmgr
and lets XORP shutdown gracefully, but ran into a bug with it deleting
interface configuration when it shuts down for any interface defined
in the config, even if "restore-original-config-on-shutdown: true" is
set.

The result on my test VM is that eth0 and lo no longer have IP addresses.

Graceful shutdown does clean up xrl socket files correctly now too.

The shutdown process is also very slow, meaning a long restart time.
I'm wondering if the work on async methods will help that in any
way...

I was also unable to get rtrmgr to use syslog.

So for an actual production environment, my current preference is to
take a huge hammer to XORP any time I need to shut it down or restart
it.

Here is the latest iteration of my init script:

----8<----
#!/bin/bash

function start {
    # Start XORP in daemon mode
    /usr/local/xorp/sbin/xorp_rtrmgr -d -P /var/run/xorp.pid -l
/var/log/xorp -b /etc/xorp/config.boot

    # Ensure XORP socket permissions are correct (required for XORP
1.7 fixed in 1.8)
    sleep 1
    chmod 775 /var/tmp/xrl.*
    chown root:xorp /var/tmp/xrl.*
}
function stop {
    # Kill the XORP router manager
    killall -q -9 xorp_rtrmgr

    # Kill any lingering XORP sub-processes (updated for 1.8)
    killall -q -9 xorp_bgp
    killall -q -9 xorp_fea
    killall -q -9 xorp_fea_dummy
    killall -q -9 xorp_fib2mrib
    killall -q -9 xorp_igmp
    killall -q -9 xorp_mld
    killall -q -9 xorp_olsr4
    killall -q -9 xorp_ospfv2
    killall -q -9 xorp_ospfv3
    killall -q -9 xorp_pimsm4
    killall -q -9 xorp_pimsm6
    killall -q -9 xorp_policy
    killall -q -9 xorp_rib
    killall -q -9 xorp_rip
    killall -q -9 xorp_ripng
    killall -q -9 xorp_static_routes
    killall -q -9 xorp_vrrp

    # Remove xorp routes from the routing table
    ip route flush proto xorp

    # Clean up XORP sockets
    rm /var/tmp/xrl.*

    # Remove PID file
    rm /var/run/xorp.pid
}
function restart {
    stop
    sleep 1
    start
}

case "$1" in
    start)
        echo -n "Starting XORP: "
        start
        echo "Done"
        ;;
    restart)
        echo -n "XORP restarting... "
        restart
        echo "done"
        ;;
    stop)
        echo -n "Stopping XORP: "
        stop
        echo "Done"
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
        ;;
esac
exit 0
----8<----

I also wrote a quick companion CRON script that will check if rtrmgr
has crashed and attempt to restart XORP if that is the case.  I
haven't run into XORP crashing while up and running personally, but
its a nice "self healing" kind of check, and doesn't cost much of
anything to do.  Pardon the echo ugliness, I wanted to write the log
file in a format consistent with XORP.

----8<----
#!/bin/bash
# This script will check to make sure that xorp_rtrmgr is running and
restart it if needed.

# Should XORP be running?  We use the existance of its PID file to find out.
if [ -f /var/run/xorp.pid ]; then
    # Does the PID file point to a running xorp_rtrmgr process?
    STATUS=$(ps `cat /var/run/xorp.pid` | grep 'xorp_rtrmgr' | wc -l)
    if [ $STATUS -eq 0 ]; then
        # XORP should be running but its not: force a restart.
        echo "[" `date +%Y/%m/%d` `date +%T`.$((10#$(date +%N) /
1000)) "ERROR xorp_monitor ] RTRMGR not running, attempting to
restart" >> /var/log/xorp
        /etc/init.d/xorp restart
    fi
fi
----8<----

I threw this in /usr/local/xorp/sbin/xorp_monitor

On Thu, Mar 17, 2011 at 3:14 AM, Ben Greear <greearb at candelatech.com> wrote:
> I've uploaded xorp 1.8.3 builds to xorp.org:
>
> http://www.xorp.org/releases/1.8.3/
>
> There are RPMs for recent Fedora, binary builds for all sorts of Fedora
> and similar OSs, and source tarball.
>
> If anyone can give these some quick testing to basically verify the
> build and packaging scripts, that would be great help!
>
> The naming could perhaps be better, so let me know if you think of
> something that makes more sense.
>
> I'll push these on to github and maybe sourceforge tomorrow if all
> goes well.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/



More information about the Xorp-hackers mailing list