Why multiple filtering databases in 802.1q?

databases

There's an annex in the 802.1Q spec that describes scenarios where shared (single filtering database) and independent (multiple filtering databases) VLAN learning are needed. Both have their merits depending on what one is trying to accomplish.

As another poster pointed out, multiple filtering databases are needed if the same MAC address appears in two VLANs on different ports of the same switch. I think (but not sure) that DECnet Phase IV routers used the same MAC address on every interface, which would fit the above scenario if it was attached to a switched network.

Without multiple filtering databases, the MAC address would be learned only in the VLAN in which it most recently appeared as a source address. The address would keep flip-flopping between the ports and traffic from one of the VLANs would be either be directed to the wrong destination, or discarded because it didn't have that port in its membership.

Anoop

databases

There's an annex in the 802.1Q spec that describes scenarios where shared (single filtering database) and independent (multiple filtering databases) VLAN learning are needed. Both have their merits depending on what one is trying to accomplish.

As another poster pointed out, multiple filtering databases are needed if the same MAC address appears in two VLANs on different ports of the same switch. I think (but not sure) that DECnet Phase IV routers used the same MAC address on every interface, which would fit the above scenario if it was attached to a switched network.

Without multiple filtering databases, the MAC address would be learned only in the VLAN in which it most recently appeared as a source address. The address would keep flip-flopping between the ports and traffic from one of the VLANs would be either be directed to the wrong destination, or discarded because it didn't have that port in its membership.

Anoop

In article , wrote: :I'm looking at Q-BRIDGE-MIB (the MIB for 802.1q bridges, as defined in :RFC 2674) and I'm trying to understand why multiple filtering databases :are useful.

Looking briefly at the RFC, it looks to me that one might have different filtering databases for different VLANs. Also, it appears one might have different virtual filtering databases, such as having one for multicast filtering that might distinct from one for unicast filtering, which might in turn be distinct from one for other purpose I haven't heard of before.

When creating a standard, it is often better to allow for the possibility of multiple instances of something and later find out that people only ever use one of them, then to allow for only one instance and later find that people are chaffing because they really need more than one.

Yes, that's the idea. Can be useful sometimes; I've been bitten by SVL switches (single database for all VLANs) and Suns with multiple interfaces in different VLANs.

Suns use the 'MAC address per device'-paradigm by default and use the same hardware address for all interfaces (I know you can change it to use the interface MAC addresses, but it isn't the default).

Switches that use separate databases for each VLAN are not bothered by this.

Regards,

Marco.

If you ever had a SUN workstation acting as a router or a XP notebook happily bridging between its wireless and wired interfaces you will know. :-)

There is some motivation in the Annex of the IEEE standards. (Keywords: Independent vs. Shared VLAN Learning).

the same MAC address may appear in different VLANs, where the bridge entry needs to point to a different physical port.

if you get this, then either the bridge ignores some bridge entries, or continually overwrites the entry, (or crashes...)

common examples used to be DECnet or OSI devices (still common in telco telemetry systems). In IP, standardised MAC address such as used in VRRP can be on multiple subnets.

A sun with multiple LAN ports normally gives them all the same MAC address - but it isnt very useful to send all traffic to just 1 port.

I thought 802.1Q was incorporated into 802.1D-2004 but I just got

802.1D-2004 and it has no such annex. I guess that was 802.1p that was incorporated into 802.1D. Oh, well.