On 02/04/2013 11:58 AM, Vlad Yasevich wrote:
On 02/04/2013 11:24 AM, Stephen Hemminger wrote:
One thing I am not clear about is whether is supposed to be just
a simple filter of VLAN traffic, or a full VLAN aware bridge.
I started with the concept of basic VLAN filtering, but it has been
morphing into more of a VLAN away bridge.
The change to make FDB entries per-VLAN seems to be the biggest tipping
point into a full VLAN bridge. I am concerned that might break existing
API's and Spanning Tree (internal and external).
I debated for a while about whether per-VLAN FDB entries were needed.
The typing point was that without it, you may end up with flopping FDB
and possible packet drops or vlan leaks, if say 2 different VMs used the
same MAC but different VLANs. Without it, there is an exploitable gap.
I've also tried to separate FDB code changes as much as possible. If
you really thing this is a big risk and a barrier to entry, then we can
drop them. I am just concerned about the hole I described above, but I
guess it is not much different then what's there now.
So I played with STP for quite a bit and found the FDB changes have
absolutely no effect on operation of STP.
Since all the vlan filtering code is mostly in forwarding path, STP
works just fine.
Looking at STP code (the one in the kernel), I don't see any
dependencies on FDB. The only userspace code I can find is from here
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git. That
only seems to ask for RTM_GETLINK, and there you will not get any vlan
information if you don't set the filter flags.
So, I don't see any API impact as far as STP is concerned.
-vlad
