Prioritize configuration from config_db over constants.yml during BBR status initialization #19590
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
Gfrom2016
changed the title
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
Gfrom2016
changed the title
ZhaohuiS
reviewed
Jul 23, 2024
Gfrom2016
force-pushed
the
change_bbr_init_hierarchy
branch
from
a8951ac
to
6f669ac
Compare
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
ZhaohuiS
reviewed
Jul 29, 2024
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
hi @Gfrom2016 could we communicate with @prsunny to make sure the understanding is fully aligned that the BBR status would be effected by peers config in constants.yaml file? And we may need to add a nightly test to cover this? |
Signed-off-by: zitingguo-ms <zitingguo@microsoft.com>
12 tasks
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@siqbal1986 Addressed your comment, please help review it again, thanks. |
8 tasks
matiAlfaro
pushed a commit
to Marvell-switching/sonic-buildimage
that referenced
this pull request
Aug 21, 2024
… status initialization (sonic-net#19590) Why I did it There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db. Work item tracking Microsoft ADO (number only): 28302790 How I did it Initialize BBR status from constants.yml only when config_db doesn't have BBR entry. How to verify it Build image and run the following: # bbr status in constants.yml is set to disabled # change the bbr status in config_db to enabled and reload config admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hset "BGP_BBR|all" "status" "enabled" (integer) 0 admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hget "BGP_BBR|all" "status" "enabled" admin@str2-7050cx3-acs-01:~$ vtysh -c 'show run' | grep 'allowas' neighbor PEER_V4 allowas-in 1 neighbor PEER_V6 allowas-in 1 admin@str2-7050cx3-acs-01:~$ sudo config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json admin@str2-7050cx3-acs-01:~$ sudo config reload -y # check bgpcfgd log, bbr default status is enabled 2024 Aug 14 05:42:47.653216 str2-7050cx3-acs-01 INFO bgp#bgpcfgd: BBRMgr::Initialized and enabled from config_db. Default state: 'enabled'
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Aug 21, 2024
… status initialization (sonic-net#19590) Why I did it There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db. Work item tracking Microsoft ADO (number only): 28302790 How I did it Initialize BBR status from constants.yml only when config_db doesn't have BBR entry. How to verify it Build image and run the following: # bbr status in constants.yml is set to disabled # change the bbr status in config_db to enabled and reload config admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hset "BGP_BBR|all" "status" "enabled" (integer) 0 admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hget "BGP_BBR|all" "status" "enabled" admin@str2-7050cx3-acs-01:~$ vtysh -c 'show run' | grep 'allowas' neighbor PEER_V4 allowas-in 1 neighbor PEER_V6 allowas-in 1 admin@str2-7050cx3-acs-01:~$ sudo config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json admin@str2-7050cx3-acs-01:~$ sudo config reload -y # check bgpcfgd log, bbr default status is enabled 2024 Aug 14 05:42:47.653216 str2-7050cx3-acs-01 INFO bgp#bgpcfgd: BBRMgr::Initialized and enabled from config_db. Default state: 'enabled'
|
Cherry-pick PR to 202305: #19974 |
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Aug 23, 2024
… status initialization (sonic-net#19590) Why I did it There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db. Work item tracking Microsoft ADO (number only): 28302790 How I did it Initialize BBR status from constants.yml only when config_db doesn't have BBR entry. How to verify it Build image and run the following: # bbr status in constants.yml is set to disabled # change the bbr status in config_db to enabled and reload config admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hset "BGP_BBR|all" "status" "enabled" (integer) 0 admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hget "BGP_BBR|all" "status" "enabled" admin@str2-7050cx3-acs-01:~$ vtysh -c 'show run' | grep 'allowas' neighbor PEER_V4 allowas-in 1 neighbor PEER_V6 allowas-in 1 admin@str2-7050cx3-acs-01:~$ sudo config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json admin@str2-7050cx3-acs-01:~$ sudo config reload -y # check bgpcfgd log, bbr default status is enabled 2024 Aug 14 05:42:47.653216 str2-7050cx3-acs-01 INFO bgp#bgpcfgd: BBRMgr::Initialized and enabled from config_db. Default state: 'enabled'
|
Cherry-pick PR to 202405: #20005 |
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Aug 27, 2024
… status initialization (sonic-net#19590) Why I did it There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db. Work item tracking Microsoft ADO (number only): 28302790 How I did it Initialize BBR status from constants.yml only when config_db doesn't have BBR entry. How to verify it Build image and run the following: # bbr status in constants.yml is set to disabled # change the bbr status in config_db to enabled and reload config admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hset "BGP_BBR|all" "status" "enabled" (integer) 0 admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hget "BGP_BBR|all" "status" "enabled" admin@str2-7050cx3-acs-01:~$ vtysh -c 'show run' | grep 'allowas' neighbor PEER_V4 allowas-in 1 neighbor PEER_V6 allowas-in 1 admin@str2-7050cx3-acs-01:~$ sudo config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json admin@str2-7050cx3-acs-01:~$ sudo config reload -y # check bgpcfgd log, bbr default status is enabled 2024 Aug 14 05:42:47.653216 str2-7050cx3-acs-01 INFO bgp#bgpcfgd: BBRMgr::Initialized and enabled from config_db. Default state: 'enabled'
|
Cherry-pick PR to 202311: #20025 |
mssonicbld
pushed a commit
that referenced
this pull request
Aug 28, 2024
… status initialization (#19590) Why I did it There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db. Work item tracking Microsoft ADO (number only): 28302790 How I did it Initialize BBR status from constants.yml only when config_db doesn't have BBR entry. How to verify it Build image and run the following: # bbr status in constants.yml is set to disabled # change the bbr status in config_db to enabled and reload config admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hset "BGP_BBR|all" "status" "enabled" (integer) 0 admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hget "BGP_BBR|all" "status" "enabled" admin@str2-7050cx3-acs-01:~$ vtysh -c 'show run' | grep 'allowas' neighbor PEER_V4 allowas-in 1 neighbor PEER_V6 allowas-in 1 admin@str2-7050cx3-acs-01:~$ sudo config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json admin@str2-7050cx3-acs-01:~$ sudo config reload -y # check bgpcfgd log, bbr default status is enabled 2024 Aug 14 05:42:47.653216 str2-7050cx3-acs-01 INFO bgp#bgpcfgd: BBRMgr::Initialized and enabled from config_db. Default state: 'enabled'
mssonicbld
added
Included in 202311 Branch
and removed
Created PR to 202311 Branch
labels
8 tasks
mssonicbld
pushed a commit
that referenced
this pull request
Oct 18, 2024
… status initialization (#19590) Why I did it There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db. Work item tracking Microsoft ADO (number only): 28302790 How I did it Initialize BBR status from constants.yml only when config_db doesn't have BBR entry. How to verify it Build image and run the following: # bbr status in constants.yml is set to disabled # change the bbr status in config_db to enabled and reload config admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hset "BGP_BBR|all" "status" "enabled" (integer) 0 admin@str2-7050cx3-acs-01:~$ redis-cli -n 4 hget "BGP_BBR|all" "status" "enabled" admin@str2-7050cx3-acs-01:~$ vtysh -c 'show run' | grep 'allowas' neighbor PEER_V4 allowas-in 1 neighbor PEER_V6 allowas-in 1 admin@str2-7050cx3-acs-01:~$ sudo config save -y Running command: /usr/local/bin/sonic-cfggen -d --print-data > /etc/sonic/config_db.json admin@str2-7050cx3-acs-01:~$ sudo config reload -y # check bgpcfgd log, bbr default status is enabled 2024 Aug 14 05:42:47.653216 str2-7050cx3-acs-01 INFO bgp#bgpcfgd: BBRMgr::Initialized and enabled from config_db. Default state: 'enabled'
mssonicbld
added
Included in 202405 Branch
and removed
Created PR to 202405 Branch
labels
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.
Why I did it
There are two places which we can configure the BBR disabled/enabled, one is constants.yml, the other is by config_db. During run time, config_db win. But at the init stage, constants.yml win. This is a wrong logic, constants.yml only win when there is no such config in the config_db.
Work item tracking
How I did it
Initialize BBR status from constants.yml only when config_db doesn't have BBR entry.
How to verify it
Build image and run the following:
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)