Hi All, I need to do some tricky filtering stuff. Can anyone tell me if any of the following are possible? * match on a combination of firewall mark AND u32 criteria. ie. handle 6 fw AND u32 match ip src 1.2.3.4/32 - to match packets from 1.2.3.4 which have been marked elsewhere OR * to OR the values of u32 matches. Something like u32 match ip src 1.2.3.4/32 OR match ip dst 1.2.3.4/32 - to match packets going to or from 1.2.3.4 OR * to use a mask on firewall marks as per iptables/ebtables MARK matches. Regards, Leigh Leigh Sharpe Network Systems Engineer Pacific Wireless Ph +61 3 9584 8966 Mob 0408 009 502 Helpdesk 1300 300 616 email lsharpe@pacificwireless.com.au web www.pacificwireless.com.au _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Or, for that matter, how to negate a u32 match. ie, match anything NOT from 1.2.3.0/24 Regards, Leigh Leigh Sharpe Network Systems Engineer Pacific Wireless Ph +61 3 9584 8966 Mob 0408 009 502 Helpdesk 1300 300 616 email lsharpe@pacificwireless.com.au web www.pacificwireless.com.au _____ From: Leigh Sharpe Sent: Wednesday, April 04, 2007 11:55 AM To: lartc Subject: [LARTC] Some advanced filtering questions Hi All, I need to do some tricky filtering stuff. Can anyone tell me if any of the following are possible? * match on a combination of firewall mark AND u32 criteria. ie. handle 6 fw AND u32 match ip src 1.2.3.4/32 - to match packets from 1.2.3.4 which have been marked elsewhere OR * to OR the values of u32 matches. Something like u32 match ip src 1.2.3.4/32 OR match ip dst 1.2.3.4/32 - to match packets going to or from 1.2.3.4 OR * to use a mask on firewall marks as per iptables/ebtables MARK matches. Regards, Leigh Leigh Sharpe Network Systems Engineer Pacific Wireless Ph +61 3 9584 8966 Mob 0408 009 502 Helpdesk 1300 300 616 email lsharpe@pacificwireless.com.au web www.pacificwireless.com.au _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Hi to all of you!! On Wednesday 04 April 2007 01:55, Leigh Sharpe wrote:> Hi All, > I need to do some tricky filtering stuff. Can anyone tell me if any of > the following are possible?I am very newby on this, but I think I get some idea of how this whole thing works, so, I want to try to answer you this (if any of you think my answers are wrong, please, correct me!!! -and of course, if you have better ideas of if you know how to do this better, just answer to this thread, I guess Leigh and me will be glad to know about you)> > * match on a combination of firewall mark AND u32 criteria. ie. handle > 6 fw AND u32 match ip src 1.2.3.4/32 - to match packets from 1.2.3.4 > which have been marked elsewhereI guess that if you want to combine filters as a conjunction, you may have two classes (parent and child), and then redirect packets matching filter number one to parent, and from the parent, redirect packets matching filter number two to the child. Maybe something like this: ... # the node where the traffic is classified tc class add ... classid 1:1 ... # just to keep first kind of traffic tc class add ... parent 1:1 classid 1:10 ... # handling traffic matching both criteria at the same time tc class add ... parent 1:10 classid 1:100 ... ... # "handle 6 fw" tc filter add ... parent 1:1 flowid 1:10 # "u32 match ip src 1.2.3.4/32" tc filter add ... parent 1:10 flowid 1:100> OR > * to OR the values of u32 matches. Something like u32 match ip src > 1.2.3.4/32 OR match ip dst 1.2.3.4/32 - to match packets going to or > from 1.2.3.4If you are looking for a disjunction, you may have one class and two filters with same parent and flowid: ... # the node where the traffic is classified tc class add ... classid 1:1 ... # handling traffic that comes or goes to 1.2.3.4 tc class add ... parent 1:1 classid 1:10 ... ... # "u32 match ip src 1.2.3.4/32" tc filter add ... parent 1:1 flowid 1:10 # "u32 match ip dst 1.2.3.4/32" tc filter add ... parent 1:1 flowid 1:10> OR > * to use a mask on firewall marks as per iptables/ebtables MARK matches.??? I need to pass this time :(> > Regards, > Leigh > > Leigh Sharpe > Network Systems Engineer > Pacific Wireless > Ph +61 3 9584 8966 > Mob 0408 009 502 > Helpdesk 1300 300 616 > email lsharpe@pacificwireless.com.au > web www.pacificwireless.com.auPS: please, sorry if my english confuse you, I know I still need to study very hard. -- Alejandro Ramos Encinosa <alex@uh.cu> Fac. Matemática Computación Universidad de La Habana
Hi Leigh,>Hi All, >I need to do some tricky filtering stuff. Can anyone tell me if any of >the following are possible? > >* match on a combination of firewall mark AND u32 criteria. ie. handle >6 fw AND u32 match ip src 1.2.3.4/32 - to match packets from 1.2.3.4 >which have been marked elsewhereyou can do that in a couple (at least) of different ways. 1) Using netfilter custom chains. All the conditions you can express with the U32 classifier can be expressed with iptables too. U32 allows you to use hash tables and speed up the classification in certain contexts, but if you are not using U32 hash tables you can replace any U32 match with an iptables mark/command. To some extent, you can define a combination of conditions using iptables custom chains: you create a chain and insert into the latter the iptables command that test your conditions. iptables allows you to use the ! (i.e. NOT) operator. This solutions however does not scale, and, depending on what configuration you need to enforce, it may not work always. This is not the solution I would suggest to use, especially if your need to define many filters. 2) Using the (relatively) new Basic classifier. More details below.>OR > >* to OR the values of u32 matches. Something like u32 match ip src >1.2.3.4/32 OR match ip dst 1.2.3.4/32 - to match packets going to or >from 1.2.3.4U32 does not allow you to explicitly OR different matches. However, you can organize your filters using U32 hash tables in a way such that on a given bucket you insert only those match conditions that must be ORed: After all, a list of matches is nothing but a list of ORed conditions: the first one that matches is used. This solution may not scale and may not be usable in all scenarios (it depends a lot on the config you need to enforce).> >OR > >* to use a mask on firewall marks as per iptables/ebtables MARKmatches. You can do that with the Basic classifier. (I believe there is also a patch around that adds this functionality to the fw classifier). The Basic classifier allows you to define conditions such as match <condition1> AND (NOT (<conditions2> OR <condition3>) Here are a couple of examples for the conditions above (see my note at the end of the email): # match ip src 1.2.3.4/32 OR match ip dst 1.2.3.4/32 tc filter add dev eth2 parent 1:0 prio 5 protocol ip \ basic match \ u32\(u32 0x01020304 0xFFFFFFFF at 12\) OR \ u32\(u32 0x01020304 0xFFFFFFFF at 16\) \ flowid 1:11 # match anything NOT from 1.2.3.0/24 tc filter add dev eth2 parent 1:0 prio 5 protocol ip \ basic match \ NOT u32\(u32 0x01020300 0xFFFFFF00 at 12\) \ flowid 1:13 # Example of mask on firewall marks # This filter matches with those pkts whose firewall # mark has the value 1 set in the least significant 4 bits # (you can use 0xF instead of 0x0000000F if you prefer) tc filter add dev eth2 parent 1:0 prio 5 protocol ip \ basic match \ meta\(nf_mark mask 0x0000000F eq 1\) \ flowid 1:12 For more detail on the Basic classifier, see these kernel configuration options: Networking +->Networking options +->QoS and/or fair queueing +->Elementary classification (BASIC) +->Extended Matches Note that the Basic classifier and the extended matches are not as mature and stable as the rest of the Traffic Control code yet. (I have fixed a few bugs both in IPROUTE2 and in the kernel; next week I am going to send the patches to the current maintainer. I can post the patches here too if there is anyone interested) Regards. /Christian [http://benve.info]
Christian Benvenuti wrote:> For more detail on the Basic classifier, see these kernel > configuration options: > > Networking > +->Networking options > +->QoS and/or fair queueing > +->Elementary classification (BASIC) > +->Extended Matches > > Note that the Basic classifier and the extended matches are not as > mature and stable as the rest of the Traffic Control code yet. > (I have fixed a few bugs both in IPROUTE2 and in the kernel; next > week I am going to send the patches to the current maintainer. > I can post the patches here too if there is anyone interested)Cool. I will see them on netdev, but if you are using them for real some examples would be usefull on here. It seems like ages ago Thomas was doing ematch/meta stuff and until now I''ve not seen one example. To Leigh - there are the other things you can do with tc actions like pipe/reclassify/continue. They are (partially/minimally) documented in iproute2''s doc/actions/*. I do have a problem with actions-general (maybe it''s just the way I read it), but the comments in the example in that just seem wrong. They are to do with policers/shared meters more than classification, but the comments and the phrase shared meter hold up the possibility of doing some cool stuff that in reality turns out to be impossible. Andy.