-
Notifications
You must be signed in to change notification settings - Fork 538
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 #2137
Handle dual ToR neighbor miss scenario #2137
Conversation
- If unable to resolve a neighbor on a dual ToR system, write a neighbor table entry for that neighbor with a zero MAC Signed-off-by: Lawrence Lee <[email protected]>
- When receiving 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. Signed-off-by: Lawrence Lee <[email protected]>
Signed-off-by: Lawrence Lee <[email protected]>
- Insert newline before open braces - Use MacAddress boolean conversion Signed-off-by: Lawrence Lee <[email protected]>
Signed-off-by: Lawrence Lee <[email protected]>
Signed-off-by: Lawrence Lee <[email protected]>
- Move standalone tunnel neighbor handling to completely separate code path Signed-off-by: Lawrence Lee <[email protected]>
Signed-off-by: Lawrence Lee <[email protected]>
- Add dual ToR neighbor miss test cases: - Create generic test runner function that executes test steps described in mux_neigh_miss_tests.py - Add neighbor miss test case with missing PEER_SWITCH config - Create setup fixtures for dual ToR DB entries - CONFIG_DB: VLAN, MUX_CABLE, PEER_SWITCH - APPL_DB: TUNNEL_DECAP_TABLE - Refactor existing tests to use setup fixtures for consistency - Create ASIC_DB and APPL_DB verification functions - Verify APPL_DB NEIGH_TABLE entry presence/absence - Verify ASIC_DB ROUTE_ENTRY and NEIGH_ENTRY entry presence/absence - Create various fixtures to generate test information Signed-off-by: Lawrence Lee <[email protected]>
Signed-off-by: Lawrence Lee <[email protected]>
58859e8
to
193a00d
Compare
This pull request introduces 2 alerts and fixes 1 when merging 193a00d into 4bff5c6 - view on LGTM.com new alerts:
fixed alerts:
|
Signed-off-by: Lawrence Lee <[email protected]>
This pull request fixes 1 alert when merging dc04459 into 4bff5c6 - view on LGTM.com fixed alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall lgtm, lets chat on the test changes.
orchagent/neighorch.cpp
Outdated
@@ -6,6 +6,7 @@ | |||
#include "routeorch.h" | |||
#include "directory.h" | |||
#include "muxorch.h" | |||
#include "observer.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this. Its already in .h file
orchagent/neighorch.cpp
Outdated
@@ -17,6 +18,8 @@ extern RouteOrch *gRouteOrch; | |||
extern FgNhgOrch *gFgNhgOrch; | |||
extern Directory<Orch*> gDirectory; | |||
|
|||
#define MUX_TUNNEL "MuxTunnel0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove. Its unused and also not relevant to neighorch
Signed-off-by: Lawrence Lee <[email protected]>
This pull request fixes 1 alert when merging 499475e into 4bff5c6 - view on LGTM.com fixed alerts:
|
This pull request fixes 1 alert when merging 499475e into 4bff5c6 - view on LGTM.com fixed alerts:
|
- 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 <[email protected]> Co-authored-by: Sumukha Tumkur Vani <[email protected]>
* 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 <[email protected]> Co-authored-by: Sumukha Tumkur Vani <[email protected]>
* 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 <[email protected]> Co-authored-by: Sumukha Tumkur Vani <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]> Signed-off-by: Lawrence Lee <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]>
When checking for route entry mismatches, ignore mismatched routes where an APPL_DB neighbor entry with a zero MAC is present. These routes are introduced by this change in SWSS and are expected: sonic-net/sonic-swss#2137 Signed-off-by: Lawrence Lee <[email protected]>
What I did
Test changes
@pytest.yield_fixture
mux_neigh_miss_tests.py
. These descriptions are used by the generic test runnertest_neighbor_miss
function to execute the test actions and verify expected resultsTest case descriptions:
Expectations:
For the purposes of this test, there is a distinction made between 'server' IPs and 'neighbor' IPs. Server IPs are IP addresses explicitly configured on a specific mux cable interface in the MUX_CABLE table in config DB. Mux cable IPs (or neighbor IPs) are any other IPs within the VLAN subnet.
Standby Mux Cable IP Unresolved Test Cases:
Active Mux Cable IP Unresolved Test Cases:
Neighbor IPs Unresolved Test Cases:
Why I did it
How I verified it
Details if related