BPDU Messages/ Multicast traffic forwarded from LAN to WAN

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Author Message
trevorj
DD-WRT Novice


Joined: 28 Jan 2014
Posts: 21

PostPosted: Thu May 09, 2019 11:05    Post subject: BPDU Messages/ Multicast traffic forwarded from LAN to WAN Reply with quote
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
Sponsor
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7025
Location: Dresden, Germany

PostPosted: Fri May 10, 2019 7:44    Post subject: Re: BPDU Messages/ Multicast traffic forwarded from LAN to W Reply with quote
trevorj wrote:
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


stp is a local property for bridge handling on the router. it has nothing todo with packet filtering or blocking. so of course anything you want will still pass the router, no matter if stp is enable or disabled. since stp is disabled i can just assume that the origin of these packets is not the router itself. you may set "filter multicast" on the security page which will disable the multicast forwarder which is mainly used for iptv applications. but as i said. a router is a router. its doing its job and routing packets from lan to wan and vice versa. but in this case i dont think thats the right answer since these multicast packets should only be seen on the local lan bridge. but with one exception. if you set wan to disabled on the setup page, the wan port becomes member of the lan bridge. then you have a perfect loopback in your setup. another interesting answer could be. your wan port and your lan ports are member of the same switch. the r7000 has in fact a 5 port switch and wan and lan port is separated by vlans which are trunked on external side. so you wont see the vlan. but in your log i see the vlan. so it seems you got to manage to see the whole switch as one unit without vlan filtering to outbound

_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
trevorj
DD-WRT Novice


Joined: 28 Jan 2014
Posts: 21

PostPosted: Fri May 10, 2019 11:09    Post subject: Reply with quote
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
DD-WRT Novice


Joined: 28 Jan 2014
Posts: 21

PostPosted: Wed Jun 12, 2019 12:31    Post subject: Reply with quote
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
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum