[BGP] starting BGP service after swss #12381
Merged
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
BGP service has always been starting after interface-config. However, recently we discovered an issue where some BGP sessions are unable to establish due to BGP daemon not able to read the interface IP. This issue was only obsered after upgrading to FRR 8.2.2. Delaying starting BGP seems to be a workaround for this issue. However, caution is that this delay might impact warm reboot timing and other timing sequences. Signed-off-by: Ying Xie <[email protected]>
lguohan
approved these changes
Oct 13, 2022
yxieca
added a commit
that referenced
this pull request
Oct 13, 2022
Why I did it BGP service has always been starting after interface-config. However, recently we discovered an issue where some BGP sessions are unable to establish due to BGP daemon not able to read the interface IP. This issue was clearly observed after upgrading to FRR 8.2.2. See more details in #12380. How I did it Delaying starting BGP seems to be a workaround for this issue. However, caution is that this delay might impact warm reboot timing and other timing sequences. This workaround is reducing the probability of hitting the issue by close to 100X. However, this workaround is not bulletproof as test shows. It is still preferrable to have a proper FRR fix and revert this change in the future. How to verify it Continuously issuing config reload and check BGP session status afterwards. Signed-off-by: Ying Xie <[email protected]>
10 tasks
|
@yxieca PR conflicts with 202012 branch |
|
Cherry-pick was done by PR #15312 |
10 tasks
yxieca
pushed a commit
that referenced
this pull request
Jun 8, 2023
11 tasks
StormLiangMS
pushed a commit
that referenced
this pull request
Aug 15, 2024
Why I did it With the following PR, make bgp start after swss. #12381 bgp started after the swss but still ahead of the interface init. Jun 12 04:53:59.768546 bjw-can-7050qx-1 NOTICE root: Starting swss service... ... Jun 12 04:54:12.725418 bjw-can-7050qx-1 NOTICE admin: Starting bgp service... ... Jun 12 04:54:43.036682 bjw-can-7050qx-1 NOTICE swss#orchagent: :- updatePortOperStatus: Port Ethernet0 oper state set from down to up Jun 12 04:54:43.191143 bjw-can-7050qx-1 NOTICE swss#orchagent: :- updatePortOperStatus: Port Ethernet4 oper state set from down to up Jun 12 04:54:43.207343 bjw-can-7050qx-1 NOTICE swss#orchagent: :- updatePortOperStatus: Port Ethernet12 oper state set from down to up Work item tracking Microsoft ADO (number only): 26557087 How I did it Check the interface status before start bgp. waiting timeout is about 60s, will output a warning message if interface still down. How to verify it build debug image, boot the image, check the syslog. and bgp process. syslog:1098:Jun 3 03:10:30.338071 str-a7060cx-acs-10 INFO bgp#root: [bgpd] It took 0.498398 seconds for interface to become ready
matiAlfaro
pushed a commit
to Marvell-switching/sonic-buildimage
that referenced
this pull request
Aug 21, 2024
Why I did it With the following PR, make bgp start after swss. sonic-net#12381 bgp started after the swss but still ahead of the interface init. Jun 12 04:53:59.768546 bjw-can-7050qx-1 NOTICE root: Starting swss service... ... Jun 12 04:54:12.725418 bjw-can-7050qx-1 NOTICE admin: Starting bgp service... ... Jun 12 04:54:43.036682 bjw-can-7050qx-1 NOTICE swss#orchagent: :- updatePortOperStatus: Port Ethernet0 oper state set from down to up Jun 12 04:54:43.191143 bjw-can-7050qx-1 NOTICE swss#orchagent: :- updatePortOperStatus: Port Ethernet4 oper state set from down to up Jun 12 04:54:43.207343 bjw-can-7050qx-1 NOTICE swss#orchagent: :- updatePortOperStatus: Port Ethernet12 oper state set from down to up Work item tracking Microsoft ADO (number only): 26557087 How I did it Check the interface status before start bgp. waiting timeout is about 60s, will output a warning message if interface still down. How to verify it build debug image, boot the image, check the syslog. and bgp process. syslog:1098:Jun 3 03:10:30.338071 str-a7060cx-acs-10 INFO bgp#root: [bgpd] It took 0.498398 seconds for interface to become ready
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
BGP service has always been starting after interface-config. However, recently we discovered an issue where some BGP sessions are unable to establish due to BGP daemon not able to read the interface IP.
This issue was clearly observed after upgrading to FRR 8.2.2. See more details in #12380.
How I did it
Delaying starting BGP seems to be a workaround for this issue.
However, caution is that this delay might impact warm reboot timing and other timing sequences.
This workaround is reducing the probability of hitting the issue by close to 100X. However, this workaround is not bulletproof as test shows. It is still preferrable to have a proper FRR fix and revert this change in the future.
How to verify it
Continuously issuing config reload and check BGP session status afterwards.
Signed-off-by: Ying Xie [email protected]
MSFT ADO: 24163872