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.
> > 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.
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.
cheers
luigi
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
