This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/PROCESSOR-SDK-AM57X: Issue with ACTIVE-BACKUP bonding driver with VLANs

Part Number: PROCESSOR-SDK-AM57X

Tool/software: Linux

Hi Support Team!

We already asked a related question and patched the Linux kernel as described here: 
https://e2e.ti.com/support/processors/f/791/t/736137?Linux-PROCESSOR-SDK-AM57X-ACTIVE-BACKUP-bonding-driver-with-VLANs

However we are still experiencing issues using the Bonding setup on the AM572x.

We are using the AM572x with VLANs on bonded interfaces eth0/eth1. The AM57x is setup to dual standalone emac mode.

Bonding Configuration is the same as described in the other thread:

# cat /etc/modprobe.d/bonding.conf
options bonding mode=active-backup max_bonds=1 miimon=100

Please see the attached picture of our test setup. The center device is configured with bonded eth0/eth1. All devices have the same HW (all are using an AM572x SOC), but only the center device is configured with active-backup bonding of eth0/eth1.

 

During the test, it was verified that always the connection which has the active bonding interface was tested.
Observations:
When the active ETH of the center gateway is connected to the ETH0 of the external gateway, the connection is working, but if the active ETH of the center gateway is connected to the ETH1 of the external gateway, there is no IP connection possible on this link.
 
The strange thing is when starting a TCPDUMP on the eth1 of the external gateway, the connection comes alive, ping and login on this connection is possible.

We are using the attached patch “cpsw-mcast-only-host-port”, taken from this site and fixed to apply for our kernel 4.9.41 because we had problems with looping ARP packets before:

Any help is much appreciated.

Thanks,
Franz Flasch
Mission Embedded GmbH/Frequentis AG

  • Hi,

    Could you post please how you are setting up  the bonding on the center GW? Without doing any ping or login requests, does TCPDUMP show any traffic?

    Best Regards,

    Schuyler

  • Hi Schuyler!

    The network is setup via systemd. Find the config files attached for the center GW (content of /etc/systemd/network)
    Bonding configuration in /etc/modprobe.d/bonding.conf :
    options bonding mode=active-backup max_bonds=1 miimon=500
     
    There is no traffic on the interfaces when there is no ping.
    Regards,
    Franz Flasch
  • Hi,

    Based on the network diagram topology and the bonding mode selected which is active backup the eth1 link looks to be operating as expected. The backup link is not showing any traffic which appears to be correct in active backup. What happens when the bonding mode is set to broadcast?

    Are there two external gateways being used here? 

    Best Regards,

    Schuyler

  • HI Schuyler!

    Thanks for the answer. Yes we are using an active/backup mode and there are 2 external GWs. The Center GW should switch to the backup GW if the active link fails. As I initially stated during the test we ensured that we always only ping the active connection.

    Means for e.g. Setup 1:

    eth0 was the active connection first and then we disconnected the left external GW to test the link with eth1. The right external GW was only pingable if we started tcpdump on the external GW. As soon as the active link from the Center GW goes to eth1 of the external GW it does not work anymore. 

    All GWs are the same devices, only with different configurations, and all are using an AM572x SoC. 

    Schuyler Patton said:
    What happens when the bonding mode is set to broadcast?

    We haven't tested broadcast mode, as we need an active/backup configuration.

    Thanks, regards,
    Franz Flasch

  • Hi,

    What happens if TCPDUMP is run on the center gateway instead of the external gateway? I am not sure yet how to determine whether this is a CPSW driver issue or a higher level network stack issue.  Is the MAC address the same for the 192.168.100.1 on both external gateways? Could the ARP table be invalid on the fail over?

    Best Regards,

    Schuyler

  • Hi,

    Since we have not heard back on the post we will assume that you were able to move past the issue and will close the thread for now. If you still need assistance on this thread you can re-open it.

    Best Regards,

    Schuyler