[libteam][warm-reboot] fix issue in teamd warm-reboot that teamd starts

[stepanblyschak]

with state of tdport from previous warm-reboot.

In case LAG was down before reboot, lacp->wr is not cleared.
In lacp_event_watch_port_flush_data we incremented nr_of_tdports and add
tdport to lacp->wr.state. In case lacp->wr.state already had this tdport
we do not set new state for tdport but appened a new item in
lacp->wr.state. In case we preformed warm-reboot and PortChannel member
was down, after reboot PortChannel member became up next warm-reboot
will initialize teamd with PortChannel member in down state.

Example of PortChannel0002 dump with single member Ethernet24 file when
this issue is reproduced:

admin@sonic:~$ sudo cat /host/warmboot/teamd/PortChannel0002
1
4
Ethernet24
0
Ethernet24
1
Ethernet24
1
Ethernet24
1

Fix this issue by calling stop_wr_mode() when LAG was down. This was probably intended but missed.

Signed-off-by: Stepan Blyschak [email protected]

Why I did it

To fix an issue seen in warm-reboot-sad test cases.

How I did it

I fixed it in SONiC libteam patch that adds warm-reboot support. Details in commit description.

How to verify it

Run warm-reboot-sad test on t0-56 topology.

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106

Description for the changelog

A picture of a cute animal (not mandatory but encouraged)

[stepanblyschak]

/azpw run

[mssonicbld]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lguohan]

is this upstreamed?

[lguohan]

@judyjoseph to check

[stepanblyschak]

is this upstreamed?

@lguohan warm-reboot feature for teamd is not upstreamed

[liat-grozovik]

@lguohan can we proceed with the approval flow?

[judyjoseph]

Thanks for the fix, yes looks like it was missed out earlier - based on the comments Pavel had put in code.. We can take it.

But in my tests I could not find a functional impact though I find the file eg: /host/warmboot/teamd/PortChannel0002 is having wrong data ( member interface getting appended on multiple warm-reboots ).

The LAG interface state comes up correctly once the member interface comes back up. Can you share the exact test sequence where you see the issue.

[stepanblyschak]

1. Have a T0 deployed topology
2. On VM1 (PortChannel0001) shutdown member port
3. On DUT observe that PortChannel0001 is down and the member is deselected
4. On DUT perform "sudo warm-reboot"
5. After warm-reboot completes (warmboot-finalizer is finished) bring the member port back up on VM1.
6. On DUT observe that PortChannel becomes up and member is selected.
7. On DUT perform "sudo warm-reboot"
8. During DUT warm boot teamd starts on PortChannel0001 - it sees wrong data (from previous boot where member was down) and falls back into cold boot mode for the LAG.
9. PortChannel0001 flaps on VM1 causing data plane disruption.

You can also run warm-reboot sad tests cases in the following order - first lag member sad test, then vlan member sad test. Vlan member sad test will fail with downtime of few sec.

[judyjoseph]

LGTM