[Oisf-devel] RFC: vlan_id in flow tracking

Victor Julien victor at inliniac.net
Mon Apr 8 12:35:24 UTC 2013


On 04/08/2013 01:44 PM, Eric Leblond wrote:
> Hi,
> 
> On Thu, 2013-04-04 at 13:10 +0200, Victor Julien wrote:
>> (RFC: request for comments :))
>>
>> Suricata currently parses VLAN headers but doesn't really do anything
>> with them. This is obviously wrong in some cases, like in flow tracking.
>> There can be several vlan's on a network, where in each we see the same
>> 5-tuple. These shouldn't be mixed, but right now they can be.
>>
>> This patch tries to deal with it:
>> https://github.com/inliniac/suricata/commit/d755fdfdc4576057712ccdb70f1e3a17bfad901c
>>
>> There are a few open issues:
>>
>> - what to do in case of multiple layers of VLAN? We should probably be
>> taking the tunnel approach, where we create a fake packet
> 
> If people are separating client networks by using first VLAN and if
> second VLAN is the one used in client network, the tunneling approach
> will not work.

How do you mean? Each vlan id should be a unique network, right?

> For now, I would say the best approach may be to use the outer VLAN id
> as tag in flow. But It might only be my way of seeing thing, so a choice
> could be done via a configuration variable.
> 
>> - there are reports of broken switches (Chris) that only append vlan
>> tags to one direction of the flows. To handle this correctly the vlan id
>> tracking would have to be optional
> 
> We have to force people to upgrade their switches. It is good for the
> economy! Seriously, VLAN tracking has to be optional even to address the
> issue with multiple layers of VLAN.
> 
> BR,
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------




More information about the Oisf-devel mailing list