From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radu Oprisan Date: Fri, 23 Jun 2006 00:11:16 +0000 Subject: Re: [LARTC] TC using vlan interface Message-Id: <449B31A4.6060500@securesystems.ro> List-Id: References: <00e801c69608$127b67e0$0900fe0a@LucianoNotebook> In-Reply-To: <00e801c69608$127b67e0$0900fe0a@LucianoNotebook> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Torsten Luettgert wrote: > On Fri, 2006-06-23 at 01:17 +0300, Radu Oprisan wrote: > >> Torsten Luettgert wrote: >> >>> On Thu, 2006-06-22 at 11:28 -0300, Luciano wrote: >>> >>> >> Let me explain... >> Due to the fact that vlan id's add some 4 bytes to the header of the >> packet, tc filter does not work properly unless you feed it with an >> offset and a hex match. I use 801.q and TC with iptables and tc filter >> rules based on iptables mark with great success. I admit it is more >> complicated this way, but it works... >> >> iptables -A FORWARD -t mangle -d xxx.xxx.xxx.xxx -j MARK --set-mark 12 >> iptables -A FORWARD -t mangle -d xxx.xxx.xxx.xxx -j RETURN >> > > Oh, I see. Didn't ever think of those problems, because I never > use tc filters. My setup would look like > > iptables -t mangle -A FORWARD -d x.y.z.t -j CLASSIFY --set-class 10:112 > Ok, you can do it with -j CLASSIFY ... forgot about that. But anyway, the best solution for this if you want speed is to adapt, as in, use the offset trick in u32. I had an email once from somebody who was kind enough to assist me in this problem and if i find it, i will gladly post the translation. Btw, all this marking and -j CLASSIFY uses quite a bit of processing power, which amounts in a bigger timespan from the time the packet enters the system until if finally leaves it. > which removes a bit of the complexity. > > Regards, > Torsten > > _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc