Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Apr 05, 2007 at 04:01:32PM -0600, Dmitry S. Makovey wrote:
>
> We've had DRBD running for quite some time and never had a problem with
> iptables configs. However this week when I was fiddling with iptables
> settings on secondary DRBD machine my primary went into "coma" when it
> stopped responding to any requests. Disabling iptables on secondary machine
> rectified the problem. So I got curious as to what caused the problem and so
> far my steps were as follows:
>
> 1. Initial state
> Configs prior to my changes looked like (everything worked as expected at that
> point):
>
> iptables at Primary:
> -A RH-Firewall-1-INPUT -s 192.168.1.45 -m state --state NEW -m tcp -p
> tcp --dport 7788 -j ACCEPT
>
> iptables at Secondary:
> -A RH-Firewall-1-INPUT -s 192.168.1.232 -m state --state NEW -m tcp -p
> tcp --dport 7788 -j ACCEPT
>
> drbd.conf:
> resource var {
> protocol C;
> incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ;
> halt -f";
> startup { wfc-timeout 0; degr-wfc-timeout 120; }
> disk { on-io-error detach; } # or panic, ...
> syncer {
> group 0;
> rate 6M;
> }
> on Primary.com {
> device /dev/drbd0;
> disk /dev/sdb3;
> address 192.168.1.232:7788;
> meta-disk internal;
> }
> on Secondary.com {
> device /dev/drbd0;
> disk /dev/sdb3;
> address 192.168.1.45:7788;
> meta-disk internal;
> }
> }
>
>
> 2. Added SNMP-enabling rule on Secondary:
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 161 -j ACCEPT
>
> 3. Restarted (reloaded) iptables:
> service iptables restart
>
> 4. Primary goes "bananas"
>
> 5. Shut down iptables on Secondary:
> service iptables stop
>
> 6. Primary is back to normal
>
> 7. Now after picking and poking and tcpdump'ing here's my working final setup:
> added to iptables at Secondary:
> -A RH-Firewall-1-INPUT -s 192.168.1.232 -m state --state NEW -m tcp -p
> tcp --sport 7788 -j ACCEPT
> the rest is without a change
>
>
> The question is: is it me doing/setting up something wrong or is it DRBD
> misbehavior? My understanding (from watching tcpdumps) is that data flow goes
> in both directions Primary<->Secondary both utilizing 7788 plus some
> high-level port. When connection breaks in one direction DRBD "doesn't like
> it" and sends Primary into some weird state.
>
> More background info:
>
> Systems:
> redhat-release-3AS-13.7.3
>
> DRBD:
> drbd-0.7.17-17
> drbd-km-2.4.21_40.ELsmp-0.7.17-17
> drbd-km-2.4.21_40.EL-0.7.17-17
does the problem persist with 0.7.23 ?
can you reproduce this with a 2.6 kernel?
any kernel messages?
please describe "some weird state" in more detail.
--
: Lars Ellenberg Tel +43-1-8178292-0 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com :
__
please use the "List-Reply" function of your email client.