[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