[netfilter-cvslog] r3587 - branches/netfilter-ha/linux-2.6

hidden at netfilter.org hidden at netfilter.org
Mon Jan 10 23:41:15 CET 2005

Author: hidden at netfilter.org
Date: 2005-01-10 23:41:15 +0100 (Mon, 10 Jan 2005)
New Revision: 3587

Revision: hidden at sch.bme.hu--2005-public/netfilter-ha--mainline--1.0--patch-12

Updated README.

* README: updated, covers the patchtree for 2.6.10, updated module
  parameters, etc.

Modified: branches/netfilter-ha/linux-2.6/README
--- branches/netfilter-ha/linux-2.6/README	2005-01-10 21:50:25 UTC (rev 3586)
+++ branches/netfilter-ha/linux-2.6/README	2005-01-10 22:41:15 UTC (rev 3587)
@@ -80,7 +80,7 @@
 Unfortunately, ct_sync depends on a couple of changes to the core
 Netfilter code, so it cannot be used without patching and recompiling your
-kernel. To make this easier, a complete patch-tree is provided.Our patch
+kernel. To make this easier, a complete patch-tree is provided. Our patch
 set is managed with quilt, so you're encouraged to apply the tree using
 quilt if you plan to contribute to the project. To do this, install quilt
 first: download from its Savannah project page
@@ -88,46 +88,35 @@
 for your favourite Linux distribution (Debian testing/unstable includes
 quilt, for example.)
-The next step is to unpack a vanilla kernel source (2.4.26 in our case),
-and make two directories for quilt: '.pc' and 'patches':
+The next step is to unpack a vanilla kernel source (2.6.10 in our case):
-hidden at nienna:patchtree$ tar xjf linux-2.4.26.tar.bz2 && cd linux-2.4.26
-hidden at nienna:linux-2.4.26$ mkdir .pc patches
+hidden at nienna:patchtree$ tar xjf linux-2.6.10.tar.bz2 && cd linux-2.6.10
-The you should copy the contents of the 'patches' directory of the CVS
-module to the 'patches' directory you've just created inside the kernel
+Now you should copy the whole 'patches' directory to the kernel source
-hidden at nienna:linux-2.4.26$ cp ~/cvs/netfilter/netfilter-ha/patches/* \
-			    patches/
+hidden at nienna:linux-2.6.10$ cp -r ~/svn/netfilter/netfilter-ha/patches .
 At this point, quilt should know everything about the patches to be
 applied. You can easily test this:
-hidden at nienna:linux-2.4.26$ quilt unapplied
+hidden at nienna:linux-2.6.10$ quilt unapplied
-To apply all those patches, type:
-hidden at nienna:linux-2.4.26$ quilt push -a
+To apply all of those patches, type:
-NOTE: the patchtree contains a few other useful goodies as well, which are
-not strictly needed by ct_sync. There are kgdb 1.9, connection marks, and
-the raw table with NOTRACK/TRACE targets. You may safely remove these from
-quilt's 'series' file if you don't need them.
+hidden at nienna:linux-2.6.10$ quilt push -a
 The patchtree does not include the actual ct_sync sources, you have to
 copy them into your kernel tree after applying the complete patchtree. To
@@ -136,36 +125,34 @@
 two lines):
 # First, we create the a new patch, which will contain our addon files
-hidden at nienna:linux-2.4.26$ quilt new ct_sync.patch
+hidden at nienna:linux-2.6.10$ quilt new ct_sync.patch
 Patch ct_sync is now on top
 # We name those files _before_ copying them to the tree
-hidden at nienna:linux-2.4.26$ quilt add include/linux/netfilter_ipv4/\
-> {cts_buff.h,ct_sync.h,ct_sync_main.h,ct_sync_proto.h,ct_sync_sock.h}
+hidden at nienna:linux-2.6.10$ quilt add include/linux/netfilter_ipv4/\
+> {cts_buff.h,ct_sync.h,ct_sync_proto.h,ct_sync_sock.h}
 File include/linux/netfilter_ipv4/cts_buff.h added to patch ct_sync
 File include/linux/netfilter_ipv4/ct_sync.h added to patch ct_sync
-File include/linux/netfilter_ipv4/ct_sync_main.h added to patch ct_sync
 File include/linux/netfilter_ipv4/ct_sync_proto.h added to patch ct_sync
 File include/linux/netfilter_ipv4/ct_sync_sock.h added to patch ct_sync
 # Add C source files
-hidden at nienna:linux-2.4.26$ quilt add net/ipv4/netfilter/\
+hidden at nienna:linux-2.6.10$ quilt add net/ipv4/netfilter/\
 > {ct_sync_main.c,ct_sync_proto.c,ct_sync_sock.c}
 File net/ipv4/netfilter/ct_sync_main.c added to patch ct_sync
 File net/ipv4/netfilter/ct_sync_proto.c added to patch ct_sync
 File net/ipv4/netfilter/ct_sync_sock.c added to patch ct_sync
-# Copy those files
-hidden at nienna:linux-2.4.26$ cp ~/cvs/netfilter/netfilter-ha/ct_sync/*.h\
+# Copy the files
+hidden at nienna:linux-2.6.10$ cp ~/cvs/netfilter/netfilter-ha/ct_sync/*.h\
 > include/linux/netfilter_ipv4
-hidden at nienna:linux-2.4.26$ cp ~/cvs/netfilter/netfilter-ha/ct_sync/*.c\
+hidden at nienna:linux-2.6.10$ cp ~/cvs/netfilter/netfilter-ha/ct_sync/*.c\
 > net/ipv4/netfilter/
 # Refresh our quilt patch
-hidden at nienna:linux-2.4.26$ quilt refresh
+hidden at nienna:linux-2.6.10$ quilt refresh
 OK, we are ready. Now run your favourite configuration tool, and enable
-the following options under Networking options/Netfilter configuration:
+the following options under Networking options/Network packet filtering/
+IP: Netfilter configuration:
-  <M> Netfilter netlink interface
-  <*> Connection tracking event notifications
-    <M> Connection tracking netlink interface
+  <*> Connection tracking events
     <M> Connection tracking state synchronization
 At this point, you're ready to recompile your kernel, and continue setting
@@ -197,9 +184,9 @@
 4. Marking traffic to be replicated
-If CONNMARK support is compiled in ct_sync does not replicate all
-conntrack entries, only those which have a special bit set in their
-connection mark field. For example: you usually don't need your
+If CONNMARK support is enabled in the kernel config then ct_sync does not
+replicate all conntrack entries, only those which have a special bit set
+in their connection mark field. For example: you usually don't need your
 administrative SSH connections to be replicated. You must use the CONNMARK
 target to mark important connections. For example, this command restores
 the old way of operation, and marks every connection:
@@ -212,14 +199,7 @@
 should be considered as the special 'to-be-synced' bit, you have to use
 the 'cmarkbit=30' parameter when loading the module.
-NOTE: the patch-tree of ct_sync contains an updated CONNMARK patch, which
-is unfortunately incompatible with older versions of iptables. If you get
-'invalid argument' errors when trying to add rules using the CONNMARK
-target, you should upgrade your iptables user-space to the CVS version, or
-apply the user-space portion of the CONNMARK patch to your iptables source
-and recompile.
 5. Loading the ct_sync module
@@ -229,33 +209,39 @@
   - syncdev: the name of the Ethernet interface connected to the
     dedicated replication network. This interface must not be used for
-    other purposes.
+    other purposes. (Mandatory!)
-  - state: decides whether the node should be a master or a slave
-    initially. It is generally a good idea to load the module as a slave,
-    and use the /proc interface later to transition into master state.
-  - id: a unique node id (possible values: 0-255), this should be
-    statically configured to distinct values on all nodes of the cluster.
   - l2drop: whether you'd like the slave nodes to drop all layer 2 (link
     layer) packets except the ones coming in on the dedicated replication
     interface if the node is slave. This can be useful to make sure that
-    only the master processes packets coming in.
+    only the master processes packets coming in. (Optional, defaults to 0
+    meaning this functionality is turned off by default.)
-All of the parameters except l2drop and cmarkbit are mandatory, ct_sync
-won't load if you don't specify them, or give an invalid value.
+  - notrack: if you set it to 1 ct_sync takes care of installing its own
+    'NOTRACK'-like Netfilter hook causing the connection tracking system
+    to skip all packets coming in or going out on the syncdev interface.
+    This means that you don't have to worry about installing iptables
+    rules using the NOTRACK target to stop synchronization traffic from
+    causing connection tracking events. (Optional, defaults to 1: enabled.)
+  - cmarkbit: see the previous section for some more information.
+The `syncdev' parameter is mandatory, ct_sync won't load unless you
+specify it. All the others are completely optional.
 6. Initiating state transitions using the /proc interface
-ct_sync creates a file in /proc/net, which contains 0 if the current state
-of the node is slave, and 1 if it is master. Transitions can be initiated
-by writing the appropriate value into this file, for example to set the
-node to master state you need to issue the following command:
+ct_sync creates its own directory in /proc/sys/net/ipv4/netfilter. A
+couple of files can be found there, out of which `state' is the most
+important. `state' contains 0 if the current state of the node is `none',
+meaning that ct_sync on that node does nothing. You can set that to either
+1 or 2 meaning slave or master, respectively. State transitions can be
+initiated by writing the appropriate value into this file, for example to
+set the node to master state you need to issue the following command:
-# echo 1 > /proc/sys/net/ipv4/netfilter/ct_sync/state
+# echo 2 > /proc/sys/net/ipv4/netfilter/ct_sync/state
 You can check if this was successful by checking the contents of the same

More information about the netfilter-cvslog mailing list