Skip to content

[bgp] Fix test_bgp_update_timer#3189

Merged
lolyu merged 1 commit intosonic-net:masterfrom
lolyu:fix_start_session
Mar 24, 2021
Merged

[bgp] Fix test_bgp_update_timer#3189
lolyu merged 1 commit intosonic-net:masterfrom
lolyu:fix_start_session

Conversation

@lolyu
Copy link
Copy Markdown
Collaborator

@lolyu lolyu commented Mar 22, 2021

Description of PR

FRR checks if a new neighbor is a already-defined neighbor within the
dynamic range. And BGPNeighbor.start_session always starts exa_bgp
then pushs the neighbor definitions to config_db. For t0 testbeds, the
neighbor is within subnet 192.168.0.0/21 that occurs to be same as the
one used by BGPVac. So after BGPNeighbor.start_session starts
exa_bgp, FRR will detects the new connections as BGPVac, so
subsequent neighbor will make FRR complain.

Signed-off-by: Longxiang Lyu lolv@microsoft.com

Summary:
Fixes #3188

Type of change

  • Bug fix
  • Testbed and Framework(new/improvement)
  • Test case(new/improvement)

Approach

What is the motivation for this PR?

As issue #3188

How did you do it?

Starts exa_bgp session after pushing neighbor definitions.

How did you verify/test it?

bgp/test_bgp_update_timer.py::test_bgp_update_timer PASSED                                                                                                                                     [100%]

===================================================================================== 1 passed in 166.85 seconds =====================================================================================

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

`FRR` checks if a new neighbor is a already-defined neighbor within the
dynamic range. And `BGPNeighbor.start_session` always starts `exa_bgp`
then pushs the neighbor definitions to config_db. For t0 testbeds, the
neighbor is within subnet `192.168.0.0/21` that occurs to be same as the
one used by `BGPVac`. So after `BGPNeighbor.start_session` starts
`exa_bgp`, `FRR` will detects the new connections as `BGPVac`, so
subsequent neighbor will make `FRR` complain.

Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
@lolyu lolyu requested a review from a team as a code owner March 22, 2021 06:09
@bingwang-ms
Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines
Copy link
Copy Markdown

Azure Pipelines successfully started running 1 pipeline(s).

@lolyu lolyu merged commit 01ee8a3 into sonic-net:master Mar 24, 2021
@lolyu lolyu deleted the fix_start_session branch March 24, 2021 07:56
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?
`FRR` checks if a new neighbor is a already-defined neighbor within the
dynamic range. And `BGPNeighbor.start_session` always starts `exa_bgp`
then pushs the neighbor definitions to config_db. For t0 testbeds, the
neighbor is within subnet `192.168.0.0/21` that occurs to be same as the
one used by `BGPVac`. So after `BGPNeighbor.start_session` starts
`exa_bgp`, `FRR` will detects the new connections as `BGPVac`, so
subsequent neighbor will make `FRR` complain.
As issue sonic-net#3188

How did you do it?
Starts exa_bgp session after pushing neighbor definitions.

Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
kazinator-arista pushed a commit to kazinator-arista/sonic-mgmt that referenced this pull request Mar 4, 2026
…atically (sonic-net#18331)

#### Why I did it
src/sonic-utilities
```
* c0ba32ad - (HEAD -> 202305, origin/202305) CLI to skip polling for periodic information for a port in DomInfoUpdateTask thread (sonic-net#3187) (16 hours ago) [mihirpat1]
* 261cfdf7 - CLI enhancements to revtrieve data from TRANSCEIVER_FIRMWARE_INFO table (sonic-net#3177) (sonic-net#3189) (19 hours ago) [mssonicbld]
* 6160ee79 - [202305][config] Add YANG alerting for override (sonic-net#3195) (20 hours ago) [jingwenxie]
* a55624d8 - [fast/warm-reboot] Put ERR message in syslog when a failure is seen (sonic-net#3186) (34 hours ago) [Vaibhav Hemant Dixit]
```
#### How I did it
#### How to verify it
#### Description for the changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[test_bgp_update_timer] loganalyzer error '% Operation not allowed on a dynamic neighbor'

2 participants