From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Ansis Atteka <aatteka@nicira.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] conntrackd: make conntrackd namespace aware
Date: Thu, 15 Nov 2012 13:20:42 +0100 [thread overview]
Message-ID: <20121115122042.GA1701@1984> (raw)
In-Reply-To: <CAA=3Oq=COQS_gYuTT3mQ5KssEdNJHAj4gYz8dcg+rfr9XA_Sdg@mail.gmail.com>
On Mon, Oct 15, 2012 at 09:55:09PM -0700, Ansis Atteka wrote:
[...]
> >> Here is how I am currently doing that:
> >>
> >> struct nethdr {
> >> #if __BYTE_ORDER == __LITTLE_ENDIAN
> >> uint8_t type:4,
> >> version:4;
> >> #elif __BYTE_ORDER == __BIG_ENDIAN
> >> uint8_t version:4,
> >> type:4;
> >> #else
> >> #error "Unknown system endianess!"
> >> #endif
> >> uint8_t flags;
> >> uint16_t len;
> >> uint32_t seq;
> >> uint32_t nsid; < -present only if nethdr.flag &
> >> };
> >> nsid is the namespace id. This field would be present only
> >> if nethdr.flags & NET_F_NAMESPACE != 0.
> >
> > That adds an always zero field for the non-namespace case in the
> > protocol fixed header. TLVs can be used for optional fields.
>
> What is your take on encapsulating namespace id in control messages
> (e.g. state resync requests)?
>
> It seems that as of now control messages do not have TLVs...
>
> Of course I could put some logic inside build.c and parse.c to deal
> with that. For example, if caller passes NULL for nf_conntrack *ct,
> then that would handle control message case?
>
> Any better ideas?
It took me a long while to decide on this, sorry for the delay.
I think adding some 32-bits ID to the nethdr is fine since I can reuse
in case I decide to support cluster-based firewall clusters composed
of more than two firewalls.
The ID will allows us to identify messages coming from different
firewall and to keep different external caches, one per node ID.
So go ahead with adding that ID to the nethdr.
next prev parent reply other threads:[~2012-11-15 12:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-01 1:11 [PATCH] conntrackd: make conntrackd namespace aware Ansis Atteka
2012-09-06 1:36 ` Ansis Atteka
2012-09-06 17:17 ` Pablo Neira Ayuso
2012-09-06 20:33 ` Ansis Atteka
2012-09-06 17:02 ` Pablo Neira Ayuso
2012-09-10 23:24 ` Ansis Atteka
2012-09-11 15:44 ` Pablo Neira Ayuso
2012-09-13 7:37 ` Ansis Atteka
2012-09-18 19:23 ` Pablo Neira Ayuso
2012-09-18 22:36 ` Ansis Atteka
2012-09-19 8:21 ` Pablo Neira Ayuso
2012-09-28 20:05 ` Ansis Atteka
2012-10-16 4:55 ` Ansis Atteka
2012-11-15 12:20 ` Pablo Neira Ayuso [this message]
2012-11-15 19:34 ` Ansis Atteka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121115122042.GA1701@1984 \
--to=pablo@netfilter.org \
--cc=aatteka@nicira.com \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).