Fran��������������������������������������������� wrote: > On Fri, 2009-10-30 at 10:20 +0100, Patrick McHardy wrote: >> Fran����������������������������������������������� wrote: >>> On Thu, 2009-10-29 at 23:30 +0100, Patrick McHardy wrote: >>>>> Would it be possible to have 64bit MARKs with 64bit architectures? >>>>> >>>>> Apparently they are defined as "unsigned long" in linux headers, but >>>>> iptables limits them to 32bit. >>>> Thats from far far back. The unsigned long only exists in compatibility >>>> structures, all new revisions use 32 bit. This is deliberate to make >>>> sure they're same-sized on all architectures and rulesets don't behave >>>> differently. >>> It might be an uncommon case, but many things I do need MARKs and 32bits >>> is just not enough! >>> >>> For example, for input traffic I do marking for: >>> - ip rules (sometimes A LOT of rules) >>> - tc filters (sometimes A LOT of filters) >>> - gateway selection (ip rules for multipath) >>> - marking input interface to use in IMQ >>> >>> Any ideas then for someone needing more than 32bits MARK? I could use >>> TOS bits (usable with ip rules and tc filters), but it's just so ugly, >>> and would screw in any network using it... >>> >>> Could the other 32 bits be used as a MARK "category" feature available >>> only for 64bit arch? >> No, as I said, rulesets are supposed to behave similar on all >> architectures. Since neither routing rules nor TC classifiers >> support more than 32 bit, it would be useless anyways. But you >> can usually deal with this by organizing your marking rules >> properly. >> >> First, all of the above support using masks for mark values, >> which might be helpful. For routing and gateway selection you >> only need the mark values at PREROUTING and OUTPUT, so you >> can reuse them afterwards. TC marking is best done in >> POSTROUTING since that doesn't interfere with routing. If >> for some reason you want to do TC classification earlier than >> that, you can use the CLASSIFY target, which doesn't use >> mark values but priority values. > > Agreed, POSTROUTING is not a problem, it's more incoming traffic. I > already play a lot with masks, the problem being that I use IMQ device > that needs tc marking in PREROUTING and unfortunately does not work with > CLASSIFY. > > I have systems with LOTS of ifaces, gateways and filters/rule which work > very nicely in multipath. > > Currently, I'm using the 32 bits as follows: > Input Iface = 5 bits (up to 32 ifaces) > Gateway = 5 bits (up to 32 gateways) > IMQ tc mark = 11 bits (up to 2048 filters) > ip rule filters = 11 bits (up to 2048 rules) > > It is quite OK for now, but I would have loved to have margin for more > rules or new features in the future (I'd like to play with NFQUEUE > things for Authentication, IDS, ... and more bits would have been cool). > > Thanks for the answer, I think I can make it trying to make more use of > u32 filters and other things. If you have any other suggestions or > ideas, I would be happy to hear them! Well, one more. You don't need any mark values for the input interface, both routing rules and TC classifiers (flow, route, meta) support iif classification directly. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
