kern/86361: bridge(4) does not work with VLAN trunks

[Peter Jeremy]

>Number:         86361
>Category:       kern
>Synopsis:       bridge(4) does not work with VLAN trunks
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Sep 20 06:10:05 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Peter Jeremy
>Release:        5.3-RELEASE-p5
>Organization:
Alcatel Australia Limited
>Environment:
FreeBSD aalp02.alcatel.com.au 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #4: Fri Feb 25 10:13:13 EST 2005     root at aalp02.alcatel.com.au:/var/obj/usr/src/sys/wansim  i386

The code has not changed in 7-CURRENT so the problem is still
presumably present.

>Description:
      bridge(4) includes code to detect network topology loops by
monitoring the MAC addresses that it sees on each bridged interface and
isolating the interface if the same source MAC address is seen on more
than one interface more than 10 times in 10 seconds.

In the case of a VLAN trunk, this check is incorrect as the MAC
addresses only need to be unique within each VLAN.  With protocols
like DECnet as well as the Cassini (ce) adaptor on Solaris, it is
normal for the same MAC address to appear in multiple VLANs,
potentially on different switches.  The behaviour of bridge(4) causes
the interfaces to be muted when this occurs.

like DECnet

simple 
>How-To-Repeat:
      Configure a host with the same MAC address on two or more NICs.
Connect the NICs to different VLANs configured on different switches.
Configure trunks on each switch containing all VLANs and connect them
to separate NICs on the FreeBSD box.

On the FreeBSD box, enable bridging between the two NICs (the NICs need
to be up but do not need to be configured with VLAN pseudo-interfaces).

Generate ethernet broadcast traffic (eg ARP requests) from all the test
interfaces and verify that the FreeBSD box reports loops.
>Fix:
      The simplest solution would seem to be to include provision for a
VLAN tag in bdg_hash_table.  This would need to be extracted from the
received packet and included in HASH_FN.
>Release-Note:
>Audit-Trail:
>Unformatted: