[CFT]: ipfw named tables / different tabletypes

[Luigi Rizzo]

On Thu, May 22, 2014 at 08:09:55PM +0400, Alexander V. Chernikov wrote:
> On 22.05.2014 19:47, Luigi Rizzo wrote:
> > On Thu, May 22, 2014 at 06:56:41PM +0400, Alexander V. Chernikov wrote:
> >> On 22.05.2014 00:48, Luigi Rizzo wrote:
> >>> On Wed, May 21, 2014 at 10:10:26PM +0400, Alexander V. Chernikov wrote:
> > ...
> >>> we can solve this by using 'low' numbers for the numeric tables
> >>> (these were limited anyways) and allocate the fake entries in
> >>> another range.
> >> Currently we have u16 space available in base opcode.
> > yes but the standard range for tables is much more limited:
> >
> > 	net.inet.ip.fw.tables_max: 128
> >
> > so one can just (say) use 32k for "old" tables and the rest
> > for tables with non numeric names.
> > Does not seem to be a problem in practice.
> Well, using upper 32k means that you set this default to 65k which 
> consumes 256k of memory on 32-bit arch.
> Embedded people won't be very happy about this (and changing table 
> numbers on resize would be a nightmare).

no no, this is an implementation detail but
within the kernel you can just remap the 'old' and 'new'
table identifiers to a single contiguous range.
The only thing you need to do is that when you push
identifiers up to userland, those with 'new' names will
be mapped to the 32-64k range.

Example:
user first specifies tables
	"18, goodguys, 530, badguys" in the same rule
   /sbin/ipfw will generate these numbers:
	18, 32768, 530, 32769 ; tlv {32768:goodguys, 32769:badguys}
   The kernel will then do a lookup of those identifiers and
	18: internal index 1, name "18"
	32768: internal index 2, name "goodguys"
	530: internal index 3, name "530"
	32769: internal index 4, name "badguys"

Then the next rule contains tables
	1, badguys, 18
    /sbin/ipfw generates
	1, 32768, 18 ; tlv {32768:badguys} // note different from before
    Kernel looks up the names and remaps
	1: internal index 5, name "1"
	32768: internal index 4, name "badguys"
	18: internal index 1, name "18"

Finally when you do an 'ipfw show' the kernel will remap names
between 1 and 32768 to themselves, and other names to 32768+
(or some other large number, say 40k and above) so
as they are found. So the rules will be pushed up with
	18, 40000, 530, 40001
	1, 40001, 18

we can discusso the other details privately

cheers
luigi


1. first, the 
> >
> >>> maybe i am missing some detail but it seems reasonably easy to implement
> >>> the atomic swap -- and the use case is when you want to move from
> >>> one configuration to a new one:
> >>> 	ipfw table foo-new flush // clear initial content
> >>> 	ipfw table foo-new add  ... <repeat as needed>
> >>> 	ipfw table swap foo-current foo-new // swap the content of the table objects
> >>>
> >>> so you preserve the semantic of the name very easily.
> >> Yes. We can easily add atomic table swap that way. However, I'm talking
> >> about different use scenario:
> >> Atomically swap entire ruleset which has some tables depency:
> >>
> >>
> >> e.g. we have:
> >>
> >> "
> >> 100 allow ip from table(TABLE1) to me
> >> 200 allow ip from table(TABLE2) to (TABLE3) 80
> >>
> >> table TABLE1 1.1.1.1/32
> >> table TABLE1 1.0.0.0/16
> >>
> >> table TABLE2 2.2.2.2/32
> >>
> >> table TABLE3 3.3.3.3/32
> >> "
> >> and we want to _atomically_ change this to
> >>
> >> "
> >> 100 allow ip from table(TABLE1) to me
> >> +200 allow ip from table(TABLE4) to any
> >> 300 allow ip from table(TABLE2) to (TABLE3) 80
> >>
> >> table TABLE1 1.1.1.1/32
> >> -table TABLE1 1.0.0.0/16
> >>
> >> -table TABLE2 2.2.2.2/32
> >> +table TABLE2 77.77.77.0/24
> >>
> >> table TABLE3 3.3.3.3/32
> >>
> >> +table TABLE4 4.4.4.4/32
> >> "
> > aargh, that's too much -- because between changing
> > one table and all tables there are infinite intermediate
> > points that all make sense.
> It depends. As I said before, we're currently solving this problem by 
> adding new rules (to set X) referencing tables from different range 
> (2048 tables per ruleset) and than doing swap.
> (And not being able to use named tables to store real names after 
> implementing them is a bit discouraging).
> 
> >
> > For those cases i think the way to go could be to
> > insert a 'disabled' new ruleset (however complex it is,
> > so it covers all possible cases), and then do the set swap,
> > or disable/enable.
> We can think of per-set arrays/namespaces of tables:
> 
> so "ipfw add 100 set X allow ipfw from table(Y) to ..." will reference 
> table Y in set X and
> "ipfw table ABC list" can differ from "ipfw table ABC set 5 list".
> 
> This behavior can break some users setups so we can provide 
> sysctl/tunable to turn this off or on.
> 
> >
> > cheers
> > luigi
> >
>