1953713_en-US

[#1]

DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port

I encountered a problem or limitation with their Ethernet Switch (dpsw) in the DPAA2 with LX2160 processor.

dpsw sends a packet back to its incoming port if the destination MAC of the packet is already learned on that port (i.e., the destination MAC is in FDB on that port).

This creates a problem when the switch is connected to a Cisco Ethernet Switch. Because Cisco Ethernet Switch CDP will perform loopback test by sending packets with the same source and destination MAC. dpsw will cause Cisco Switch shutting down the port.

There is a workaround suggested by NXP. Write a script that scans the MAC addresses in FDB on each port, and add them to ACL to block them sending back to incoming port.

For example, if I need to fix the problem on eth2, use the following script

tc qdisc add dev eth2 clsact
dest=`bridge fdb show | grep -i eth2 | grep -i self | awk  '{print substr($1,0,17)}'`

for dmac in $dest; do
tc filter add dev eth2 ingress flower dst_mac $dmac skip_sw action drop done

What commands do:

 - create a qdisc (see the link I sent you with the ACLs)

 - dump the bridge FDB and display all the entries with dest port eth2 that also are of type "self"

The result of the dump is passed to awk that will print only the dmacs from the FDB:

e.g.: 00:04:9f:05:c3:c8 00:04:9f:05:c3:c9 00:04:9f:05:85:b2

-save the result in dest. -iterate in dest and add ACL filter on ingress for each mac in dest.

All the flows that will be received on  eth2  and will have a dmac in the above range will be dropped by the ACL rules created.

But this workaround seems kluge.  Here are some issues.

 - There is still a small window (between MAC is learned and MAC is placed on ACL), packets still could loopback to incoming port.

 - Also when device moves, the MAC in the ACL will not be removed. The moved device may not be reachable now.

 - The performance impact with constant scanning, adding to ACL and processing ACL.

My question: Are there any better ways to handle this?

Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port

"Maybe" this below method would work/help? Please check it and provide feedback whether it works or makes sense:

--------------------------------------------------------------------------------------------------
Alternate sample method to drop 0x9000 eth-type loopback-detection frames inbound on dpsw ports
----------------------------------------------------------------------------------------------

say if the loopback-detection frames (eth-type 0x9000) packets are coming in through eth5 dpsw-port (and for example if dpmac-18 is linked to this dpsw-port),
then running the hardware-offloaded rule would be better option by dropping the generic eth-type 0x9000 frames (irrespective of the mac-addresses)

1. Clean up any temporary/existing configuration

tc qdisc del dev eth5 clsact 2>/dev/null
tc qdisc add dev eth5 clsact

2. Apply the strict hardware-offload drop rule

tc filter add dev eth5 ingress protocol 0x9000 flower skip_sw action drop

----------------------
3. Status checks:

tc -s filter show dev eth5 ingress

restool dpsw info dpsw.0 | grep -A 10 "dpmac.18" | grep "fltr_frame"

OR

while :; do restool dpsw info dpsw.0 | grep -A 10 "dpmac.18" | grep "fltr_frame"; sleep 1; done

Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port

The short answer is that it is very unlikely to provide an implementation for the customer:

-hardware does not support source port pruning and the firmware requires significant changes (not even sure if it's feasible) for such a feature as there is no possibility to emulate the  pruning in an autonomous way.

Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port

Discussing with the AE team.