Re: [PATCH] conntrackd: make conntrackd namespace aware

[Ansis Atteka <aatteka@nicira.com>]

On Thu, Nov 15, 2012 at 2:20 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 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.

I have been on vacations for the last month. I will get back on this
multi-namespace patch sometime next week.

It seems that we actually would prefer TLV ID (so that ID could be an
arbitrary string. For example,if namespaces are named the same way on
both firewalls, then the namespace name could be used as this ID).
Otherwise this 32-bit ID would be an extra thing that needs to be
negotiated between all firewalls.

The only problem is that as of now control messages do not have this
payload where to put TLV variables. I will refresh my memory on
options here, once I will get back.