[trevorj]

Dear All,

I’ve discovered what I consider to be a rather important default config omission or bug with the latest DD-WRT firmware on a Netgear R7000.

It appears that BPDU (Bridge Protocol Data Unit) data messages are being passed from the LAN to the WAN when STP is disabled on the router.

In my test scenario, I have a DD-WRT R7000 connected via its WAN port to a Cisco Switch Port configured as Access for a particular VLAN.

If I plug in a Cisco Switch via a TRUNK Port to one of the LAN ports on my R7000 it appears BPDU messages via Multicast to destination MAC (01:80:C2:00:00:00,[1] or 01:00:0C:CC:CC:CD for Per VLAN Spanning Tree) are forwarded to the WAN port.

This then causes the WAN port to get blocked on the upstream Cisco switch with the following in the log:-

1y23w: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk GigabitEthernet0/2 VLAN2.
1y23w: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking GigabitEthernet0/2 on VLAN0002. Inconsistent port type.

This happens because the Upstream port is not a Trunk port and does not expect to see the BPDU messages being forwarded to the WAN from the LAN.

A workaround on the upstream switch is to set spanning-tree bpdufilter enable on the interface.

However, I don’t think these BPDU messages/ Multicast traffic should be passed through from the LAN to the WAN in a default configuration.

I’ve checked and STP is disabled in two places on the R7000, the Current Bridging Table under Networking and Optional Settings under the WAN setup.

I’ve enabled IGMP Snooping which has had no effect. This is what I would expect as It should only really work for LAN/WIFI based traffic in this scenario with WAN Multicast filtering enabled.

I note there is the option to block inbound Multicast traffic from the WAN to the LAN which is enabled.

Perhaps it would be a good idea to have a block Multicast from the LAN to WAN or at least STP/BPDU for anything to the following Multicast addresses:-

01:00:0C:CC:CC:CC, Field 0x0802 CDP |(Cisco Discovery Protocol), VTP (VLAN Trunking Protocol)

01:00:0C:CC:CC:CD, Field 0x0802 Cisco Shared Spanning Tree Protocol Address

01:80:C2:00:00:00, Field 0x0802 Spanning Tree Protocol (for bridges) IEEE 802.1D

01:80:C2:00:00:08, Field 0x0802 Spanning Tree Protocol (for provider bridges) IEEE 802.1ad

What do you all think?

Best Regards,

TJ

[BrainSlayer]

[trevorj]

Hi,

The Log from my upstream Cisco connected to the R7000’s WAN port shows that port is a member of VLAN 2 configured in Access mode to that VLAN. It is just a coincidence that this happens to be the internal VLAN used on the R7000 for the WAN port in its default configuration.

Multicast filtering is usually applied at a multicast boundary in this case the router as a means to prevent unintended leakage of multicast traffic beyond its desired scope.

I would therefore not expect to see Multicast traffic being forwarded to the WAN from the LAN unless it is specifically and therefore intentionally being routed using multicast routing protocols such as PIM-SM over a router-based network. Most routers with their default firmware’s connected to an ISP network, will by default filter all Multicast traffic from the LAN to WAN as it is generally undesired.

As there is already a Filter Multicast option under Block WAN requests to stop inbound Multicast. How about adding a block LAN to WAN multicast in Additional Filters under the Security TAB and having this enabled by default?

[trevorj]

Hi BrainSlayer,

I was just wondering if there was any update on filtering Multicast traffic so that it does not leak to the WAN from the LAN.

Thanks,

TJ