Re: ebtables & VLAN redirect

[Grant Taylor <gtaylor@riverviewtech.net>]

On 06/29/10 13:15, Anatoly Muliarski wrote:
> Session may be not fully correct word - more precisely it should 
> understand as IP traffic flows specified by address:port pairs to 
> dump the traffic.

So you are wanting to mirror specific flows that are passing through 
your system to VLAN 9.

What interfaces are these flows being passed through?  The bridge and 
another (virtual) interface?  In other words, what would be an example 
of an incoming interface and an out going interface?  Or is this traffic 
making it to your system because it is multicast / flooded on each VLAN?

> Your explanation is correct BUT in current bridging model there would 
> be a hundred attempts to flood ALL broadcast/multicast traffic 
> received from every bridge port. Yes, I can filter them out by using 
> ebtables rules, but this unnecessary attempts will waste CPU time.

Ok.  Just my opinion, but if this system is being designed to do this 
(presuming there are not other options) I'd make sure that the CPU was 
scaled to function with the amount of traffic.

> Writing "to limit traffic direction between bridge devices" I meant 
> there is no support to exclude attempts of flood to ALL ports by 
> limiting a direction of flooding in the description of a bridge 
> device.

Ok...  Now it sounds like you are wanting some more advanced features 
(read things that purposefully break standards in some situations) like 
broadcast storm protection.

> OK bridging will work, but I am afraid to meet performance issues 
> afterwards as I stated above.

Maybe, maybe not.

> Very interesting.

*nod*

> Thank you for your advise, It worth to employ ebtables in solving my 
> tasks. And I have met the same problem with MACs in other project and 
> I had to generate different source MACs for different VLANs and 
> eventually I had to replace the switch to cope with the problem of 
> matching destination MACs for different VLANs.

I'm starting to wonder if your system isn't being used as a traditional 
piece of network infrastructure equipment (router / switch / bridge). 
Rather if you are trying to make a utility that will ""extend a 
monitoring package that is designed to monitor one VLAN in such a way 
that it can monitor multiple VLANs.  Or at least bridge the traffic you 
want to monitor from multiple VLANs down to one VLAN that your 
application can monitor.

If this is the case, and you are using separate VLANs to avoid network 
congestion problems, I agree that bridging might not be the best option 
here.

In this case, I'd look at doing something that will cause your system to 
receive the traffic you are interested in and pass on to the monitoring 
application.  -  I'm guessing that an application layer gateway would 
probably be best at doing this.

The simple fact that you have the amount of incoming traffic that you 
want to filter and forward a subset of implies that there will be CPU 
time spent analyzing which traffic to forward.



Grant. . . .