On 01/26/2013 08:49 PM, Christian Hammers wrote:
Hello
Am Mon, 31 Dec 2012 02:12:29 +0100
schrieb Hans van Kranenburg hans.van.kranenb...@mendix.com:
Hi Daniel,
It seems there has not been any feedback on a suggested patch to the
init script for about three years?
Is there any information available on this bug? I walked into this
issue after about a day of testing, so either I'm doing things nobody
ever tried, which seems unlikely, or something's not right.
Would the following patch do what you want?
-=(/etc/quagga)# diff -u
~james/debian/quagga/quagga-0.99.21/debian/quagga.init.d /etc/init.d/quagga
--- /srv/home/james/debian/quagga/quagga-0.99.21/debian/quagga.init.d
2012-05-06 23:26:22.0 +0200
+++ /etc/init.d/quagga 2013-01-26 20:48:13.0 +0100
@@ -272,8 +272,10 @@
stop_watchquagga
stop_prio 0 $2
- echo Removing all routes made by zebra.
- ip route flush proto zebra
+ if [ -z $2 -o $2 = zebra ]; then
+ echo Removing all routes made by zebra.
+ ip route flush proto zebra
+ fi
;;
restart|force-reload)
bye,
-christian-
I guess restarting or stopping zebra is a no-go at all when other
daemons are still running, and it should probably be discouraged,
prevented or made impossible by the init script. When I restart zebra,
routes learned via other protocols will not be added back when zebra
starts again, which results in a permanently broken router.
If I comment out the line containing 'ip route flush proto zebra',
routes are still gone when restarting only zebra. Only zebra-specific
routes are added, routes from other protocols won't. Zebra removed the
routes itself, so it seems the ip route command isn't needed anyway?
Zebra seems to have an option switch, '-r', to prevent it from removing
all routes when stopping.
(http://www.nongnu.org/quagga/docs/docs-info.html#SEC33) This option can
be added in /etc/quagga/debian/conf. When I set this option routes are
still gone after /etc/init.d/quagga restart zebra
After also adding the -k option, all routes are kept intact when I do an
/etc/init.d/quagga restart zebra. They are not removed at stop, nor
removed at start o
f zebra.
/etc/quagga 0-# git diff
diff --git a/init.d/quagga b/init.d/quagga
index 0ea542c..dc19d5f 100755
--- a/init.d/quagga
+++ b/init.d/quagga
@@ -272,8 +272,8 @@ case $1 in
stop_watchquagga
stop_prio 0 $2
- echo Removing all routes made by zebra.
- ip route flush proto zebra
+ #echo Removing all routes made by zebra.
+ #ip route flush proto zebra
;;
restart|force-reload)
diff --git a/quagga/debian.conf b/quagga/debian.conf
index 8e2592d..448b969 100644
--- a/quagga/debian.conf
+++ b/quagga/debian.conf
@@ -4,7 +4,7 @@
# Check /etc/pam.d/quagga if you intend to use vtysh!
#
vtysh_enable=yes
-zebra_options= --daemon -A 127.0.0.1
+zebra_options=-r -k --daemon -A 127.0.0.1
bgpd_options= --daemon -A 127.0.0.1
ospfd_options= --daemon -A 127.0.0.1
ospf6d_options= --daemon -A ::1
But even in that case... It seems doing a /etc/init.d/quagga stop ospfd
does not make ospfd tell zebra to remove ospf learned routes when it
shuts down? /etc/init.d/quagga stop bgpd does not make bgpd tell zebra
to remove bgp routes (well, your peers will for sure remove routed
pointing to you...)? So, it's some sort of a mess here... OSPF routes
could be valid for a while when retained.
Considering all of the above... I really don't know.
The only case I could think of when you explicitely might want to remove
all zebra routes would be when doing a full stop with /etc/init.d/quagga
stop. But! restart is implemented as stop, sleep, start, which will mess
up again...
To fix this, e.g. bgpd needs to tell zebra what to remove when it's
shutting down, zebra should obviously not shut down or restart when any
other proto is running, and when it restarts anyway, it should get back
in sync with other daemons.
An option resulting in less surprise and breakage-by-default for users
would probably be to make the above changes, and keep as much rules as
possible.
I didn't test what happens when restarting zebra, then making changes in
routing, to see what zebra does with kept routes that are invalid.
--
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenb...@mendix.com | www.mendix.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
