-
Notifications
You must be signed in to change notification settings - Fork 771
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
Add a test case to verify that BGP packets use queue7 #8097
Conversation
* All control packets including BGP are expected to use Q7, separate from data packet queues Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
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:
|
Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
* Check all queues for the test instead of just q0 * Remove check for q7 counters until regression due to sonic-net/sonic-swss#2143 is fixed * Perform interface queue counter checks only once when there are v4 and v6 neighbors over the same interface Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Cherry-pick PR to 202305: #9991 |
@prabhataravind This is a new case. Generally, we only backport bug fixes to release branches. Can you elaborate why this PR is also required for 202205 and 202012 branch? |
@wangxin, Neetha added request labels for these branches. I also think this is a good test case for all release branches.. BGP packets using another queue can potentially lead to unwanted BGP flaps in production. This was a repair item for an issue found in 201911 but also seen on 202012 and 202205 on certain bcm and cisco platforms.. |
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
@wangxin , please help expediting the cherry-pick, thanks. |
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Cherry-pick PR to 202012: #10641 |
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Cherry-pick PR to 202205: #10642 |
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
@prabhataravind FYI, we need to skip this test case for some platforms that do not have QoS related feature supported |
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
Description of PR
Summary:
Fixes #7695
Type of change
Back port request
Approach
What is the motivation for this PR?
It was observed that control packets use queue 0 in TD2 platforms which can lead to these packets being lost when link utilization becomes close to 100%. This can lead to critical issues in field like BGP keepalive failures. This management test is a way to make sure that this doesn't happen again in production.
How did you do it?
By bringing up BGP sessions with neighbors and making sure that BGP control traffic uses queue 7 by default using "show queue counters".
How did you verify/test it?
By running the test and making sure that it works as expected, reporting success or failure depending on which queues are used by control packets.
Any platform specific information?
This is applicable to all platforms.
Supported testbed topology if it's a new test case?
Documentation