[DRBD-user] (possibly) noob iptables+DRBD question

Dmitry S. Makovey dmitry at athabascau.ca
Fri Apr 6 00:01:32 CEST 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

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 

iptables at Primary:
-A RH-Firewall-1-INPUT -s -m state --state NEW -m tcp -p 
tcp --dport 7788 -j ACCEPT

iptables at Secondary:
-A RH-Firewall-1-INPUT -s -m state --state NEW -m tcp -p 
tcp --dport 7788 -j ACCEPT

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;
    meta-disk internal;
  on Secondary.com {
    device /dev/drbd0;
    disk /dev/sdb3;
    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 -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:



Dmitry Makovey
Web Systems Administrator
Athabasca University
(780) 675-6245
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070405/8e8f3107/attachment.pgp>

More information about the drbd-user mailing list