[test_route_flap] Route flap multi-dut fix if the selected duthost has downstream neighbors#11677
Conversation
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
| if 'minigraph_port_name_to_alias_map' in mg_facts else {} | ||
| for neighbor in neighs: | ||
| local_ip = neighs[neighbor]['local_addr'] | ||
| nbr_port = get_port_by_ip(config_facts, local_ip) |
There was a problem hiding this comment.
nbr_port could be Ethernet<> or PortChannel<>.. right?
how are you handling portchannel case here?
There was a problem hiding this comment.
'dev_port' which is passed to this method 'get_neighbor_info' either can be Portchannel<> or Ethernet<>.
And get_port_by_ip method above returns the nbr_port based on the dut config_facts of 'PORTCHANNEL_INTERFACE' and 'INTERFACE'. So, if the nbr_port returned by get_port_by_ip method is a Portchannel<> which can be directly same as 'dev_port' passed through 'get_neighbor_info'. Using that, we are fetching the neighbor's name and its type.
But if the nbr_port returned by 'get_port_by_ip' is Ethernet<>, it is actually alias interface name, not the actual interface name. So, we get the actual interface name using the port_name_to_alias_map from minigraph facts for fetching the neighbor's name and its type.
There was a problem hiding this comment.
got it. thanks for the explanation..
|
Before the PR change: Test fetches only the ptf receiving ports of the DUT under test. T1 neighbor routes are same in all downstream DUTs. ping packet gets forwarded to other T1 neighbor DUT's ports instead of the DUT ports under test. After the PR change: Test fetches all the ptf receiving ports of all of the DUTs which has same type of neighbors similar to dut under test. Due to this change, we are making sure ping packet is received on any of the DUTs' ptf ports having similar neighbors (T1/T3). |
|
LGTM |
|
@judyjoseph the changes look good to me.. Please help with the merge. |
|
@sanjair-git PR conflicts with 202205 branch |
|
@sanjair-git PR conflicts with 202305 branch |
…s downstream neighbors (sonic-net#11677) * route-flap: Generic fix for issue-11460 * flake8 fix
|
Cherry-pick PR to 202311: #12101 |
…s downstream neighbors (#11677) * route-flap: Generic fix for issue-11460 * flake8 fix
…s downstream neighbors (sonic-net#11677) * route-flap: Generic fix for issue-11460 * flake8 fix
…s downstream neighbors (sonic-net#11677) * route-flap: Generic fix for issue-11460 * flake8 fix
|
@sanjair-git please create PR for 202205/202305 as their is conflict in cherry-pick. |
@abdosi , For both 202205/202305, cherry-pick PRs have been created already. Please see below, |
…uthost has downstream neighbors (#11677) (#12137) This is cherry-pick PR for 202205 branch. Original PR #11677 This PR fixes issue #11460 What is the motivation for this PR? * For T2 Chassis(topo-t2), route/test_route_flap works fine, if the selected duthost has upstream T3 neighbors. * Similarly, if the selected duthost has downstream T1 neighbors and if there is only one dut with T1 neighbors, test works fine too. * But if the selected duthost has downstream T1 neighbors and if there are more than one dut with downstream neighbors, route/test_route_flap fails. How did you do it? * Fetch the 'neighbor type' (LeafRouter/SpineRouter/AZNGhub) based on the chosen dev_port from get_dev_port_and_route * Get all the neighbors of same neighbor type and fetch the ptf receiving ports list based on the retrieved neighbors list. Pass the received ptf ports list to send_recv_ping_packet method for further testing. How did you verify/test it? Ran route/test_route_flap test case on T2 Chassis with 'topo-t2' topology having 3-line cards with at least 2 cards having downstream T1 neighbors. Test passes. Before the PR change: Test fetches only the ptf receiving ports of the DUT under test. T1 neighbor routes are same in all downstream DUTs. ping packet gets forwarded to other T1 neighbor DUT's ports instead of the DUT ports under test. After the PR change: Test fetches all the ptf receiving ports of all of the DUTs which has same type of neighbors similar to dut under test. Due to this change, we are making sure ping packet is received on any of the DUTs' ptf ports having similar neighbors (T1/T3).
Description of PR
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
How did you do it?
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation