[muxorch] Always use direct link for SoC IPs #2369
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lolyu
force-pushed
the
use_direct_link_soc_ip
branch
from
e22d09a
to
0b2c2ed
Compare
prsunny
requested changes
Jul 6, 2022
OK, I will change it to simply skip the neighbor handler |
lolyu
force-pushed
the
use_direct_link_soc_ip
branch
from
0b2c2ed
to
1fcfeb2
Compare
|
Propose to have it as below:
|
lolyu
force-pushed
the
use_direct_link_soc_ip
branch
from
1fcfeb2
to
ca28572
Compare
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
lolyu
force-pushed
the
use_direct_link_soc_ip
branch
from
ca28572
to
11a8fff
Compare
|
This pull request introduces 1 alert when merging 11a8fff into bf91a49 - view on LGTM.com new alerts:
|
prsunny
reviewed
Jul 10, 2022
|
@lolyu , please dont force-push. I would like to review incremental changes. |
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
prsunny
reviewed
Jul 13, 2022
| @@ -534,6 +534,11 @@ bool MuxCable::nbrHandler(bool enable, bool update_rt) | |||
| void MuxCable::updateNeighbor(NextHopKey nh, bool add) | |||
| { | |||
| sai_object_id_t tnh = mux_orch_->getNextHopTunnelId(MUX_TUNNEL, peer_ip4_); | |||
| if (add && skip_neighbors_.find(nh.ip_address) != skip_neighbors_.end()) | |||
There was a problem hiding this comment.
Can you check if a 'del' operation does not impact the code flow?
There was a problem hiding this comment.
Verified the del operation, all works well.
prsunny
approved these changes
Jul 14, 2022
yxieca
pushed a commit
that referenced
this pull request
Jul 17, 2022
What I did For SoC IPs of ports in active-active cable type, if mux is toggled to standby, still use direct link instead of changing next-hop to the tunnel. Why I did it In an active-active dualtor setup, changing the nexthop of route to SoC IP to the tunnel will have the following problem: If lower ToR is already standby, and somehow the upper ToR decides to toggle itself to standby, the toggle will fail: linkmgrd decide to toggle to standby --> muxorch disables the SoC IP neighbor and change the route next-hop to the tunnel --> ycabled could not setup gRPC connection. How I verified it Add unittest and verify the change on active-active testbeds.
preetham-singh
pushed a commit
to preetham-singh/sonic-swss
that referenced
this pull request
Aug 6, 2022
What I did For SoC IPs of ports in active-active cable type, if mux is toggled to standby, still use direct link instead of changing next-hop to the tunnel. Why I did it In an active-active dualtor setup, changing the nexthop of route to SoC IP to the tunnel will have the following problem: If lower ToR is already standby, and somehow the upper ToR decides to toggle itself to standby, the toggle will fail: linkmgrd decide to toggle to standby --> muxorch disables the SoC IP neighbor and change the route next-hop to the tunnel --> ycabled could not setup gRPC connection. How I verified it Add unittest and verify the change on active-active testbeds.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I did
For SoC IPs of ports in
active-activecable type, if mux is toggled to standby, still use direct link instead of changing next-hop to the tunnel.Why I did it
In an
active-activedualtor setup, changing the nexthop of route to SoC IP to the tunnel will have the following problem:If lower ToR is already standby, and somehow the upper ToR decides to toggle itself to standby, the toggle will fail:
linkmgrd decide to toggle to standby --> muxorch disables the SoC IP neighbor and change the route next-hop to the tunnel --> ycabled could not setup gRPC connection.
How I verified it
Add unittest and verify the change on
active-activetestbeds.Details if related