| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4CB792E0.5030704@navigue.com> Date: Thu, 14 Oct 2010 19:31:44 -0400 From: Jonathan Thibault <jonathan@...igue.com> To: netdev@...r.kernel.org Subject: Couple tc filter questions. Since the lartc mailing list appears to be dead, I'll ask here and hope not to offend anyone. 1- This page: http://lartc.org/howto/lartc.qdisc.filters.html States: "Also, with HTB, you should attach all filters to the root!" Why? Is it still true? My setup would be a lot easier with cascading filters. If it's just a matter of there not being any efficiency gains from cascading filters, that's fine. If there is a risk of things exploding randomly and without notice, I'd be keen to know. Testing shows that cascading works okay, but I haven't tried under any serious load. 2- Are filter flowid (classify) actions terminating? Meaning if two consecutive filters would match the same packet, only the first match would ever apply and no further filter is evaluated? Are there actions for which this isn't the case? Intuitively and experimentally, I'd answer no but if anyone knowledgeable in the matter would care to expand on that topic I'd be grateful. Especially considering cascading classes/filters. Another area where termination isn't entirely clear is when using mirred and ifb devices. I might want to send a copy of all my traffic to an ifb device, but then I would still want subsequent filters to match in the current qdisc. In such a case, a filter that matches all traffic with a mirred action should probably not be terminating. Maybe I'm thinking too much in terms of iptables here :P Jonathan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists