ARP: Modified '/arp/test_neighbor_mac_noptf.py' testcase to skip 'bgp shutdown all' for modular chassis #3788
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
oxygen980
changed the title
abdosi
reviewed
Jul 21, 2021
| pytest.fail('BGP Shutdown Timeout: BGP route removal exceeded 120 seconds.') | ||
| if not duthost.get_facts().get("modular_chassis"): | ||
| duthost.command("sudo config bgp shutdown all") | ||
| if not wait_until(120, 2.0, self._check_no_bgp_routes, duthost): |
There was a problem hiding this comment.
can _check_no_bgp_routes be updated for VOQ chassis to check on eBGP routes and skip other routes ?
abdosi
approved these changes
Jul 21, 2021
|
@Azure/sonic-chassis |
arlakshm
approved these changes
Jul 22, 2021
vmittal-msft
pushed a commit
to vmittal-msft/sonic-mgmt
that referenced
this pull request
Sep 28, 2021
) What is the motivation for this PR? Teat case 'arp/test_neighbor_mac_noptf.py' brings all bgp down, In case of Modular chassis testcase fails because VOQ chassis has extra routes so when script brings bgp down and verify for the routes and expects routes should be zero never works. How did you do it? To Take care of this failure, we do not shutdown all BGP neighbors for a modular chassis. The reasons are:- When we bring BGP down using 'sudo config bgp shutdown all' on VOQ chassis linecard, it only brings down the eBGP neighbors, and not the BGP_VOQ_CHASSIS_NEIGHBORs (the iBGP neighbors to other asics in the chassis) The asic has routes that are learnt from other remote asics in the chassis. VoQ architecture adds static routes for inband interfaces and all eBGP peers on the remote asics as well. To get all the routes to be flushed could be very complex. Also, the reason that the BGP shutdown was added was because on some DUT's are overwhelmed with the BGP updates and thus causing this test to intermittently fail. However, we don't see such intermittent failure on linecards of a VoQ chassis which has 12K routes in a T2 topology - possibly because CPU is powerful.
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.
Description of PR
This PR is to skip 'bgp shutdown all' for modular chassis in arp/test_neighbor_mac_noptf.py
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
Teat case 'arp/test_neighbor_mac_noptf.py' brings all bgp down, In case of Modular chassis testcase fails because VOQ chassis has extra routes so when script brings bgp down and verify for the routes and expects routes should be zero never works.
How did you do it?
To Take care of this failure, we do not shutdown all BGP neighbors for a modular chassis.
The reasons are:-
To get all the routes to be flushed could be very complex. Also, the reason that the BGP shutdown was added was because on some DUT's are overwhelmed with the BGP updates and thus causing this test to intermittently fail. However, we don't see such intermittent failure on linecards of a VoQ chassis which has 12K routes in a T2 topology - possibly because CPU is powerful.
How did you verify/test it?
Verified on VOQ chassis
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation