The Residential Gateway blocks Spanning Tree Protocol frames


The 4-port Ethernet switch built into the U-verse residential gateway does not implement the IEEE 802.1d spanning tree protocol, nor does it pass through STP messages from other switches that do implement the protocol. This can cause an inadvertent forwarding loop if a bridge loop is completed through the 3800's built-in Ethernet switch.


The 2WIRE 3800 HGV-B Residential Gateway (RG) currently used in U-verse installations includes a 4-port Ethernet switch for customer computers and other network devices. In many if not most home installations, this will be the only switch on the network.

Users with more than four network devices might add ports with one or more unmanaged Ethernet switches. As long as you avoid loops in the topology (which is mandatory with these switches to avoid forwarding loops) this will usually work fine. If this is your situation, and it most likely is, then you need not read further.

But watch out if you use the 3800 in a larger network with switches that use the IEEE 802.1d spanning tree protocol (STP).

Switches that implement the STP relax the restriction on switch loops. If you create one, the STP will discover it and temporarily block one or more switch ports as necessary to leave a spanning tree that covers all the nodes. If a switch or link fails, the STP will notice and unblock a previously blocked port to create a new spanning tree that, if possible, still covers all the nodes. The STP lets you create a network with redundant links that can be brought into use when links or switches fail, and this can be important to uptime in larger and more complex networks.

Switches that implement the spanning tree protocol transmit special messages called Bridge Protocol Data Units (BPDUs) to the special Ethernet multicast address 01:80:C2:00:00:00. Switches send a "hello" BPDU every two seconds to notify its neighbors of its existence and status. Because a BPDU is an ordinary Ethernet multicast frame, a switch that doesn't implement the STP should handle it like any other multicast frame by passing it onto all ports except the one on which it arrived. In this way, switches that implement the STP can be interconnected with switches that don't, provided that the non-STP switches never form a loop by themselves. When a switch participates in the STP, it generates its own BPDUs and will not pass on those from its neighbors.

But a switch must do one or the other, and the problem with the 3800 is that it does neither. It doesn't participate in the STP, yet it also blocks the BPDU multicasts from any switches that may be connected to it. (My guess is that the 3800 can implement the STP, but for some reason it has been turned off. Otherwise it would have no reason not to pass BPDUs along with every other Ethernet multicast; the only distinguishing feature of the BPDU is the special multicast address.)

This means that STP-speaking bridges connected through the 3800 will not see each other, so if the 3800 closes a loop the STP-speaking bridges will not detect it. A switching loop is the result. The symptoms of an active switching loop is a network that is essentially locked up and unusable, with solid activity on the lights.

The workaround for this problem is to insert another Ethernet switch between the 3800 and the rest of your network so that BPDUs do not have to pass between ports in the 3800. The extra switch may or may not implement the STP, though of course if it doesn't implement the STP it must transparently pass BPDUs. This is less than desirable since it requires an extra device and creates a single point of failure -- and the whole point of the STP is to help you avoid single points of failure. If this extra switch, or its connection to the 3800, fails, it will disconnect your network from the outside world.

Phil Karn,
Last modified: Tue Jan 12 16:22:30 PST 2010