Hi, At this point I'm tempted to explicitly *not* roll support for IPFW1 in XORP's ACL manager precisely because of its limitations; see below.
On Tue, Dec 14, 2004 at 03:19:28PM +0100, Andre Oppermann wrote: > IPFW2 does have this functionality. It's called "sets" of rules which > you can atomically swap, enable, disable, flush and intermix with each > other. It's there, read ipfw(8), it's on the 15th line. OK. This is probably something I can deal with. Basically XORP has an intermediate rule representation which tries to be generic enough to deal with divergent packet filter implementations across various OS platforms, and yet specific enough to be useful. A XORP rule tuple looks like this: ifname, vifname, src, dst, proto, sport, dport, action Rule matches take place on all fields but the 'action' part of the tuple. The interface to XORP's packet ACL manager is transaction driven to ensure atomicity. Where this atomicity can't be guaranteed by the underlying back-end, the back-end should attempt to mimic it using whatever tricks are necessary. Snapshots get taken at two levels: XORP's intermediate representation described above, and the back-end's state. These snapshots can be taken either for the purpose of safely rolling back state when rulesets are being changed, or for communicating rulesets between different parts of the packet ACL system. I would imagine that mapping between an IPFW2 'set' and a PaIpfwBackend snapshot on the fly would do the trick. I just committed the core of XORP's ACL manager last week, please feel free to have a look at it and give me feedback. Regards, BMS
pgpTebyZM8mlB.pgp
Description: PGP signature
