Date: Thu, 22 May 2014 20:09:55 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Luigi Rizzo <luigi@freebsd.org>, FreeBSD Net <net@freebsd.org> Subject: Re: [CFT]: ipfw named tables / different tabletypes Message-ID: <537E2153.1040005@FreeBSD.org> In-Reply-To: <20140522154740.GA76448@onelab2.iet.unipi.it> References: <5379FE3C.6060501@FreeBSD.org> <20140521111002.GB62462@onelab2.iet.unipi.it> <537CEC12.8050404@FreeBSD.org> <20140521204826.GA67124@onelab2.iet.unipi.it> <537E1029.70007@FreeBSD.org> <20140522154740.GA76448@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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). > >>> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537E2153.1040005>