[OpenWrt-Devel] qca8x DSA: Configured Switch Sends Packets Out Wrong Interface

[Christian Lamparter]

On Mon, Apr 1, 2019 at 6:05 PM Jeff Kletsky <lede at allycomm.com> wrote:
> qca8x DSA: Configured Switch Sends Packets Out Wrong Interface
>
> Using qca8k and ipqess on an EA8300 (ipq40xx) under Linux 4.19 based
> on patches from chunkeey's staging tree[1] as well as a patch to
> resolve the NPE issue[2].
>
> Once the switch has been configured (this is *after* the power-on
> config has been overridden), I see that packets are being sent out
> over ports that aren't associated with the bridge. As these packets
> are not seen with tcpdump on the underlying interface, I believe that
> they are traveling through the switch fabric.
>
>   * Am I configuring the bridge as expected?
Likely.

>   * Are there patches that I am missing?
Have you checked upstream netdev-next or the netdev mailinglist for
related commits?

> I have tried configuring the bridge both using /etc/config/network (no
> switch-related sections) as well as "manually" with iproute2
> commands and see the same behavior in both cases. In both cases,
> `brctl show` and `bridge link` output is consistent with that
> expected; the expected interfaces are present and those not involved
> in the bridge are not present.
>
> The initial test was for the "desired" configuration:
>
>   * lan1 -------- stand-alone 192.168.1.1/24
>   * lan2    -|
>   * lan3    -| -- bridged
>   * lan4    -|
>   * wan0.10 -|
>   * wan0.NNNN  -- other trunked VLANs -- to Cisco SG300
>
> config interface 'lan'
>         option type 'bridge'
>         option ifname 'lan2 lan3 lan4 wan0.10'
>         option proto 'static'
>         option stp '1'
>         option ipaddr '10.X.Y.Z'
>         option netmask '255.255.255.0'
>
> (wan0.10 configured and brought up elsewhere)
>
> This appeared to work for connectivity to the device itself, but a
> wired client plugged into lan2 was unable to obtain a DHCP lease from
> the DHCP server connected to the Cisco SG300, leading to this exploration.
>
> Examining the packets seen by this client suggested that they were
> being sent out lan2-4 as tagged VLAN 10 (unexpected).

As far as the switch is concerned, it's set to "port-based" mode. So it will
not do any VLAN processing (as compared to ar40xx), it's basically acting
as a dump switch. Which is probably why you are getting VLAN-tagged
frames there.

Question is: Do you also see other frame that are passed from the WAN
Port which are not tagged as VLAN 10 too?

> (I need to re-confirm this as the EA8300 at the time "won" STP root.)
>
>
> I then removed wan.10 from the bridge and connected lan4 to
> an untagged source of the 10.X.Y.Z/24 traffic from the SG300
>
>   * lan1 ----- stand-alone 192.168.1.1/24
>   * lan2 -|
>   * lan3 -| -- bridged
>   * lan4 -|
>
> config interface 'lan'
>         option type 'bridge'
>         option ifname 'lan2 lan3 lan4'
>         option proto 'static'
>         option stp '1'
>         option ipaddr '10.X.Y.Z'
>         option netmask '255.255.255.0'
>
> Looking at the packets on the lan1 port, traffic that was clearly from
> the subnet associated with the 10 VLAN was being seen (unexpected).
>
> Looking at lan1 with `tcpdump -ni lan1` only showed an occasional ARP
> related to the 192.168.1.1/24 subnet (as expected).
>
> This suggests to me that the packets are flowing through the switch
> fabric, not the CPU.
>
>
> Configuring lan1 as a bridge rather than a direct-accessed interface
> did not change the behavior.
>
> (This continued to occur after changing the STP priority of the SG300,
> rebooting the router, and confirming that the SG300 was the STP root.)
>
>
> Configuring with iproute2 commands after removing the applicable
> interface section from /etc/config/network did not change the behavior
>
>      #!/bin/sh
>
>      ip addr add 192.168.1.1/24 dev lan1
>
>      for if in lan1 lan2 lan3 lan4 wan0 ; do
>          ip link set ${if} up
>      done
>
>      ip link add name lan-br type bridge
>      ip link set lan-br type bridge stp_state 1
>
>      ip addr add 10.X.Y.Z/24 dev lan-br
>
>      ip link set lan-br up
>
>      for if in lan2 lan3 lan4 ; do
>          ip link set ${if} master lan-br
>      done
>
>
>
> Based on these observations, I believe that the switch fabric is not
> being properly configured, that I am missing patches causing the
> former, or that I am somehow not configuring the bridge properly.
Well, I think what's happened is that the switch is told (by wan.10) to
bridge the ports together, which it happily does. What's missing here
might be something in the DSA subsystem itself, that checks if the
switch can perform the necessary filtering and detagging before setting
up the fabric.But this would also require to route the traffic through the
CPU and back.


> Any suggestions as to how to proceed?
Isn't this what we all have signed up for? To come up with answers and
solutions from seemingly nothing and in the process impress others?

Cheers,
Christian

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel