[ovs-discuss] L7-filter and Openvswitch

Franck Baudin franck.baudin at qosmos.com
Tue Oct 7 07:47:53 UTC 2014


Hi Thomas,
On 10/06/14 01:41, Thomas Graf wrote:
> On 10/02/14 at 03:45pm, Franck Baudin wrote:
>> Good idea! This should be enough for, to reuse Justin's denomination, a
>> "limited L7 matching": protocols like DNS, Skype or BitTorrent cannot be
>> recognized with regex only.
>>
>> How to you foresee the OF matcher definition? Would you go for a "regexp"
>> syntax, or a generic denomination permitting the usage of different
>> L7-classifier, for instance:
>>      in_port=5,regex="GET "
>> versus something like "engine-name:engine-match"
>>      in_port=5,l7=textsearch:"GET "
>>
>> In the second way, several L7-classifier could be used (in addition or in
>> replacement), without any OF matcher modification, as l7=XXX match or
>> doesn't match. The expressiveness/richness of XXX is L7-classifier
>> dependent. And depending of the traffic, one L7-classifier could be a better
>> fit like another one, for instance an L7-classifier dedicated to protocols
>> over HTTP. Also, several L7-classifier could be used at the same time.
> I would definitely prefer specifying the search algo with the pattern
> as many uses will not require an expensive state machine search but
> can use optimized text search algorithms. That said, this needs a lot
> more discussion as this is a serious expansion of the scope of a flow
> key.
One non intrusive way to extend the flow key is to run the regex before 
the key lookup, and to extend the flow key with the result and not the 
regex itself. For instance, the regex result is a 32 bits, encoding the 
list of the matching regex.

It's like loading the skb->mark (already part of the flow key) with a 
value reflecting the matching result. This is very simple from an 
implementation perspective at the flow table level.

Best Regards,
Franck



More information about the discuss mailing list