Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[teammgrd]during warm-reboot teamd need to recover system-id from saved lacp-pdu #1003

Merged
merged 2 commits into from
Dec 1, 2019

Conversation

shine4chen
Copy link
Contributor

@shine4chen shine4chen commented Jul 30, 2019

Signed-off-by: shine.chen shine.chen@nephosinc.com

What I did

  • When creating new portchannel, teammgrd gets the MAC from the saved LACP PDU and updates the port-channel MAC accordingly.
  • Pls refer to MCLAG-HLD for details.

Why I did it

  • In MC-LAG scenario, two peer devices form one end point of a LAG, these two devices must have the same MAC address since it’s used for LACP. During warm-reboot, this MAC must not be changed.

How I verified it

  • test it on nephos lab. With this approach we observe zero packet loss during mclag warm-reboot procedure.

Details if related

Signed-off-by: shine.chen <shine.chen@nephosinc.com>
@shine4chen shine4chen changed the title [teammgrd]during warm-reboot teamd need to use same system-id before warm-reboot [teammgrd]during warm-reboot teamd need to recover same system-id from saved lacp-pdu Jul 30, 2019
@shine4chen shine4chen changed the title [teammgrd]during warm-reboot teamd need to recover same system-id from saved lacp-pdu [teammgrd]during warm-reboot teamd need to recover system-id from saved lacp-pdu Jul 30, 2019
@lguohan
Copy link
Contributor

lguohan commented Jul 31, 2019

vs test missing.

@lguohan lguohan requested a review from stcheng July 31, 2019 17:08
@shine4chen
Copy link
Contributor Author

@lguohan Teammgrd runs in teamd docker. Originally we want to add some vs test cases. But we find the existing vs image don't include teamd docker. We can add vs test cases soon after teamd docker is added in vs image.

@adyeung
Copy link

adyeung commented Sep 18, 2019

BRCM team has completed the review, we have no further request or comment to add, please proceed to the next steps.

Copy link

@adyeung adyeung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BRCM team has completed the review, we have no further request or comment to add, please proceed to the next steps.

@lguohan lguohan assigned pavel-shirshov and unassigned stcheng Nov 12, 2019
@pavel-shirshov
Copy link
Contributor

@shine4chen
How "correct" mac address is going to be set initially, before it is saved to a file?
Why mac address from config db is considered as incorrect?

@jianjundong
Copy link

@shine4chen
How "correct" mac address is going to be set initially, before it is saved to a file?
Why mac address from config db is considered as incorrect?

@pavel-shirshov : Teamd saved the last PDU from partner per port in /var/warmboot/teamd/, the mac address of this device that saved in the PDU may be different to the mac address in config db. For example, in MCLAG scenario, the standby device will change the local mac address to the mac address of active device. If the standby device is warm rebooted, this mac address must be the same as that before warm-restart, if not, the portchannel will be broken and the data forwarding may be blocked.

Copy link
Contributor

@pavel-shirshov pavel-shirshov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As comments.

cfgmgr/teammgr.cpp Outdated Show resolved Hide resolved
cfgmgr/teammgr.cpp Outdated Show resolved Hide resolved
cfgmgr/teammgr.cpp Outdated Show resolved Hide resolved
Signed-off-by: shine.chen <shine.chen@mediatek.com>
@pavel-shirshov
Copy link
Contributor

retest this please

1 similar comment
@shine4chen
Copy link
Contributor Author

retest this please

@pavel-shirshov
Copy link
Contributor

@shine4chen Can you please check why checks are failing?

@shine4chen
Copy link
Contributor Author

shine4chen commented Nov 21, 2019

@pavel-shirshov I analysised 32 failed test cases and found two root cause.

  1. Cmd ip link add pensive_ishi type veth peer name eth1 executes failed which result in the failure of DockerVirtualSwitch.
  2. In this vs test environment frr-vrf-patch is NOT imported which result in the failure of some vrf related test cases. I know frr-vrf-patch is merged to master branch. But for some environment issue the build failed, so vs test still gets the obsolete build artifact.
    Anyway neither is connected to this PR.

@shine4chen
Copy link
Contributor Author

retest this please

5 similar comments
@shine4chen
Copy link
Contributor Author

retest this please

@shine4chen
Copy link
Contributor Author

retest this please

@pavel-shirshov
Copy link
Contributor

retest this please

@shine4chen
Copy link
Contributor Author

retest this please

@shine4chen
Copy link
Contributor Author

retest this please

@pavel-shirshov pavel-shirshov merged commit 7bf63a0 into sonic-net:master Dec 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants