[Oisf-devel] RFC: vlan_id in flow tracking

[Eric Leblond]

Hi,

On Mon, 2013-04-08 at 16:53 +0200, Victor Julien wrote:
> On 04/08/2013 03:47 PM, Eric Leblond wrote:
> > Hi,
> > 
> > On Mon, 2013-04-08 at 15:13 +0200, Victor Julien wrote:
> >> On 04/08/2013 03:00 PM, Eric Leblond wrote:
> >>> Hi,
> >>>
> >>> On Mon, 2013-04-08 at 14:35 +0200, Victor Julien wrote:
> >>>> On 04/08/2013 01:44 PM, Eric Leblond wrote:
> >>>>> Hi,
...
> >>> where Network (private IP for example) may be shared among client. And
> >>> if we have no luck, then we can cross beams and have two clients with
> >>> same network under the same VLAN. 
> >>
> >> Right, I think I get the point. If we would have:
> >>
> >> [vlan 1][vlan 2][client net 1]
> >> [vlan 2][vlan 2][client net 2]
> >>
> >> We might mix both as we first peel off the outer vlan and then have no
> >> way of distinguishing between the 2 client nets anymore, right?
> > 
> > Exactly!
> > 
> >> So if we have multiple layers, we'd need multiple tags in our flow hashing?
> >>
> >> [vlan 1][vlan 2][client net 1]
> >> [vlan 2][vlan 2][client net 2]
> >>
> >> Here both tag 1 and 2 would be needed to get flows for "client net 1"
> >> and tag 2 and 2 would be needed to get "client net 2". Make sense?
> > 
> > Yes, this is the best behavior. 
> 
> RFC:
> https://github.com/inliniac/suricata/commit/e2693b6ce6ae5f7e43da26b47fdc2220dc1c3fa5

I've got few comments on it but to consider the perspective of MPLS
support. In this case, we will have the MPLS label to separate
clients/network in the same way has it is done with vlan id. Maybe we
could use a pointer inside the flow structure to indicate the
"separator" field. This would also be of use if we consider a set of GRE
tunnels used to separate network.

> >> In my patch I have a u16 for padding, so I could add support for dual
> >> layer vlans easily. For more... well that would be more work. Maybe we
> >> can just limit to 2 layers.
> > 
> > From http://en.wikipedia.org/wiki/IEEE_802.1Q triple tagging is not
> > standard.
> 
> I added a check for this in my RFC patch above.

It seems clean.

> > By the way, tagging host in the same way will be needed (thinking to
> > threshold mainly).
> 
> Right. That is going to be interesting wrt IPrep :) Maybe I should move
> iprep out of the hosts.

Yes, multi-client is something that would result in some complex and
huge work :)

BR,
-- 
Eric Leblond <eric at regit.org>
Blog: https://home.regit.org/