Your message dated Sat, 27 May 2023 05:04:07 +0000
with message-id <[email protected]>
and subject line Bug#1036316: Removed package(s) from unstable
has caused the Debian Bug report #226905,
regarding vrrpd : non RFC physical MAC use is subject to troubles
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
226905: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=226905
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: vrrpd
Version: 0.7-2
Severity: normal
On some systems, we get the slave pretending to become master whereas
the real master is still on line and acting correctly. It happens once
in a while. The scenario is this one:
-slave receive master HELLO (tcpdump show them) but vrrp timer triggers
?!? and slave start thinking it is master. It sends gratuituous ARP and
all routers start sending it traffic. After a few seconds, it sees that
master is there and release the IP address.
No-one ever send back ARP to tell the routers that it should direct
traffic back to real master, and service is broken.
Attached is a patch (diff -Naur) that will not correct this, but at
least make the service back asap. It prooved to be efficient enough so
that no user ever complained again, but we are still investigating the
root problem.
When in master state, each HELLO received is already analysed to see if
we should give back master state to another node.
RFC says that slaves do not tallk on the network, they should only
listen. So if we are in master state and get HELLO packet with lower
prio than ours, that means that someone tried to still service from us.
We react with sending gratuituous ARP to tell everyone who's the master.
Furthermore, we log this bad situation so that administrators now there
is something not usual happening.
Pascal Lengard
diff -Naur vrrpd-0.7c-script/Changes vrrpd-0.7d-cm/Changes
--- vrrpd-0.7c-script/Changes 2004-01-09 13:47:09.000000000 +0100
+++ vrrpd-0.7d-cm/Changes 2004-01-09 13:51:51.000000000 +0100
@@ -1,3 +1,26 @@
+- Pascal Lengard : counter measures
+ when we are not using vrrp mac address (we use physical mac),
+ master node HAS to be the last one who broadcast ARP for IP
+ address. Unfortunately we got examples of standby node taking
+ role of master and advertising his own MAC although real
+ master is still there. While investigating the reason for this
+ problem, I added what I called counter-measures to ensure that
+ even when this thing happen the master is the last to
+ advertise his MAC for the virtual IP.
+
+ if you get some warning about counter measure in your logs but
+ you do not have any problem accessing your server, counter
+ measures have saved you :-))
+
+ This is a deviation from RFC but using physical MAC is already
+ one, and this is triggered only when we have already lost so ...
+ can only bring good.
+
+ Modified files: vrrpd.c
+
+
+
+
- Pascal Lengard : Launch an external script on state switch.
modified files : vrrpd.c vrrpd.h vrrp_switch /var/lib/vrrpd
doc:
diff -Naur vrrpd-0.7c-script/vrrpd.c vrrpd-0.7d-cm/vrrpd.c
--- vrrpd-0.7c-script/vrrpd.c 2004-01-09 13:47:41.000000000 +0100
+++ vrrpd-0.7d-cm/vrrpd.c 2004-01-09 13:57:52.000000000 +0100
@@ -13,6 +13,11 @@
*
* Changes:
* Pascal Lengard
+ * <+> Use counter measures when detecting that slave pretends
+ * to take the service whereas it should not.
+ * this is only necessary when using physical MAC address
+ * instead of RFC preconised vrrp MAC address.
+ * Pascal Lengard
* <+> Launch a script ( /etc/vrrpd/vrrp_switch )
* when switching state. script get 2 arguments:
* $1 = new state (master or slave)
@@ -1477,6 +1482,7 @@
int len = 0;
int buflen = 0;
int delay = 3*vsrv->adver_int + VRRP_TIMER_SKEW(vsrv);
+ int i;
struct iphdr *iph;
vrrp_pkt *hd;
@@ -1535,7 +1541,15 @@
VRRP_TIMER_CLR( vsrv->adver_timer );
state_leave_master( vsrv, 0 );
vsrv->state = VRRP_STATE_BACK;
+ } else {
+ // PLuG added to understand our vrrp problems ...
+ // But it prooved to be efficient and triggers ONLY when there is already
+ // a "silent" problem. At least we get the problem logged and service
resumed.
+ syslog (LOG_WARNING,"WARNING: Sending counter measures (vrid
%d)!!\n",vsrv->vrid);
+ for( i = 0; i < vsrv->naddr; i++ )
+ send_gratuitous_arp( vsrv, vsrv->vaddr[i].addr, 1 );
}
+
free(buf);
}
--- End Message ---
--- Begin Message ---
Version: 1.0-2+rm
Dear submitter,
as the package vrrpd has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/1036316
The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.
Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)
--- End Message ---
