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

Handle dual ToR neighbor miss scenario #2151

Merged
merged 8 commits into from
Aug 20, 2022

Conversation

theasianpianist
Copy link
Contributor

@theasianpianist theasianpianist commented Feb 19, 2022

This is the master branch duplicate of PR #2137

Signed-off-by: Lawrence Lee lawlee@microsoft.com
Co-authored-by: Sumukha Tumkur Vani stumkurv@microsoft.com

What I did
Orchagent changes:

  • When orchagent receives a neighbor update with a zero MAC:
    • If the neighbor IP is configured for a specific mux cable port in the MUX_CABLE table in CONFIG_DB, handle the neighbor normally (if active for the port, no action is needed. if standby, a tunnel route is created for the neighbor IP)
    • If the neighbor IP is not configured for a specific port, create a tunnel route for the IP to the peer switch.
      • When these neighbor IPs are eventually resolved, remove the tunnel route and handle the neighbor normally.
  • When creating/initializing a mux cable object, set the internal state to standby to match the constructor behavior.

Test changes:

  • Various formatting fixes inside test_mux.py
  • Remove references to deprecated @pytest.yield_fixture
  • Add dual ToR neighbor miss test cases:
    • Test cases and expected results are described in mux_neigh_miss_tests.py. These descriptions are used by the generic test runner test_neighbor_miss function to execute the test actions and verify expected results
    • Various setup fixtures and test info fixtures were added
    • Existing test cases were changed to use these setup fixtures for consistency
  • In test_nhg.py, start interface MACs from "00:00:00:00:00:01" instead of "00:00:00:00:00:00". The above orchagent changes mean that tests using zero MAC as an interface MAC may fail

Why I did it

How I verified it

Details if related

- When orchagent receives a neighbor update with a zero MAC:
    - If the neighbor IP is configured for a specific mux cable port in the MUX_CABLE table in CONFIG_DB, handle the neighbor normally (if active for the port, no action is needed. if standby, a tunnel route is created for the neighbor IP)
    - If the neighbor IP is not configured for a specific port, create a tunnel route for the IP to the peer switch.
        - When these neighbor IPs are eventually resolved, remove the tunnel route and handle the neighbor normally.
- When creating/initializing a mux cable object, set the internal state to standby to match the constructor behavior.

- Various formatting fixes inside test_mux.py
- Remove references to deprecated `@pytest.yield_fixture`
- Add dual ToR neighbor miss test cases:
    - Test cases and expected results are described in `mux_neigh_miss_tests.py`. These descriptions are used by the generic test runner `test_neighbor_miss` function to execute the test actions and verify expected results
    - Various setup fixtures and test info fixtures were added
    - Existing test cases were changed to use these setup fixtures for consistency

Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Co-authored-by: Sumukha Tumkur Vani <stumkurv@microsoft.com>
@lgtm-com
Copy link

lgtm-com bot commented Feb 19, 2022

This pull request fixes 1 alert when merging 17ae951 into 5a651d0 - view on LGTM.com

fixed alerts:

  • 1 for Unused import

1 similar comment
@lgtm-com
Copy link

lgtm-com bot commented Feb 22, 2022

This pull request fixes 1 alert when merging 17ae951 into 5a651d0 - view on LGTM.com

fixed alerts:

  • 1 for Unused import

@theasianpianist
Copy link
Contributor Author

/Azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@theasianpianist
Copy link
Contributor Author

/Azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@lgtm-com
Copy link

lgtm-com bot commented May 26, 2022

This pull request introduces 4 alerts when merging 66b5055 into 0e5e7ba - view on LGTM.com

new alerts:

  • 2 for Wrong number of arguments in a call
  • 1 for Unused local variable
  • 1 for Variable defined multiple times

Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
@lgtm-com
Copy link

lgtm-com bot commented May 26, 2022

This pull request introduces 4 alerts when merging 4708357 into d7b5ff7 - view on LGTM.com

new alerts:

  • 2 for Wrong number of arguments in a call
  • 1 for Unused local variable
  • 1 for Variable defined multiple times

prsunny
prsunny previously approved these changes Jul 29, 2022
@lgtm-com
Copy link

lgtm-com bot commented Jul 29, 2022

This pull request introduces 4 alerts when merging a72d155 into 3161eaa - view on LGTM.com

new alerts:

  • 2 for Wrong number of arguments in a call
  • 1 for Unused local variable
  • 1 for Variable defined multiple times

Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
prsunny
prsunny previously approved these changes Aug 1, 2022
prsunny
prsunny previously approved these changes Aug 11, 2022
@prsunny
Copy link
Collaborator

prsunny commented Aug 12, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@prsunny
Copy link
Collaborator

prsunny commented Aug 18, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
@yxieca yxieca merged commit dec4570 into sonic-net:master Aug 20, 2022
yxieca pushed a commit that referenced this pull request Aug 20, 2022
* Handle dual ToR neighbor miss scenario (#2137)

- When orchagent receives a neighbor update with a zero MAC:
    - If the neighbor IP is configured for a specific mux cable port in the MUX_CABLE table in CONFIG_DB, handle the neighbor normally (if active for the port, no action is needed. if standby, a tunnel route is created for the neighbor IP)
    - If the neighbor IP is not configured for a specific port, create a tunnel route for the IP to the peer switch.
        - When these neighbor IPs are eventually resolved, remove the tunnel route and handle the neighbor normally.
- When creating/initializing a mux cable object, set the internal state to standby to match the constructor behavior.

- Various formatting fixes inside test_mux.py
- Remove references to deprecated `@pytest.yield_fixture`
- Add dual ToR neighbor miss test cases:
    - Test cases and expected results are described in `mux_neigh_miss_tests.py`. These descriptions are used by the generic test runner `test_neighbor_miss` function to execute the test actions and verify expected results
    - Various setup fixtures and test info fixtures were added
    - Existing test cases were changed to use these setup fixtures for consistency

Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Co-authored-by: Sumukha Tumkur Vani <stumkurv@microsoft.com>
dprital added a commit to dprital/sonic-buildimage that referenced this pull request Aug 29, 2022
Update sonic-swss submodule pointer to include the following:
* Dynamic port configuration - add port buffer cfg to the port ref counter ([sonic-net#2194](sonic-net/sonic-swss#2194))
* tlm_teamd: Filter portchannel subinterface events from STATE_DB LAG_TABLE ([sonic-net#2408](sonic-net/sonic-swss#2408))
* [counters] Improve performance by polling only configured ports buffer queue/pg counters ([sonic-net#2360](sonic-net/sonic-swss#2360))
* added support for Xsight platform ([sonic-net#2426](sonic-net/sonic-swss#2426))
* [ci][asan] add DVS tests run with ASAN ([sonic-net#2363](sonic-net/sonic-swss#2363))
* Handle dual ToR neighbor miss scenario ([sonic-net#2151](sonic-net/sonic-swss#2151))
* Upstream new development on p4orch ([sonic-net#2237](sonic-net/sonic-swss#2237))
* [lgtm] Fix dependency ([sonic-net#2419](sonic-net/sonic-swss#2419))
* [muxorch] Returning true if nbr in skip_neighbor_ in isNeighborActive() ([sonic-net#2415](sonic-net/sonic-swss#2415))
* [macsec]: Set MTU for MACsec ([sonic-net#2398](sonic-net/sonic-swss#2398))
* Delete Invalid if condition in intfsorch.cpp ([sonic-net#2411](sonic-net/sonic-swss#2411))

Signed-off-by: dprital <drorp@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants