Skip to content
New issue

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

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

Already on GitHub? # 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>
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants