BGP [T2] - Update neighbor admin down only for specific asic under test

[sanjair-git]

Description of PR

Summary:
Fixes # (issue)

• This PR fixes issue on 'test_bgp_peer_shutdown.py', when the test runs on T2 multi-asic dut.
• Whole test operates on one of the asic but during bgp teardown session; while removing newly added neighbor config, test runs sonic-db-cli command on both asics of the dut, which creates a dummy neighbor entry on the other asic.
• Due to this, test fails with the following reason,

                with capture_bgp_packages_to_file(duthost, "any", bgp_pcap, n0.namespace):
                    n0.teardown_session()
                    if not wait_until(
                        WAIT_TIMEOUT,
                        5,
                        20,
                        lambda: is_neighbor_session_down(duthost, n0),
                    ):
>                       pytest.fail("Could not tear down bgp session")
E                       Failed: Could not tear down bgp session

Type of change

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

Back port request

• 202012
• 202205
• 202305
• 202311
• 202405

Approach

What is the motivation for this PR?

• Test creates a dummy bgp neighbor entry on the other asic, where the test is not operating. Due to this test fails.

For example, dummy entry 20.0.0.1 on the other asic is shown below.

 show ip bgp sum 

IPv4 Unicast Summary (VRF default):
BGP router identifier 8.0.0.2, local AS number 65100 vrf-id 0
BGP table version 4468
RIB entries 3245, using 710 KiB of memory
Peers 6, using 4348 KiB of memory
Peer groups 4, using 256 bytes of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.0.7        4      65200     29995     30093        0    0    0 1d00h57m         1057     1611 ARISTA04T3
10.0.0.11       4      65200     29994     30094        0    0    0 1d00h57m         1058     1611 ARISTA06T3
20.0.0.1        4          0         0         0        0    0    0    never      Connect        0 N/A
3.3.3.0         4      65100     29964     29991        0    0    0 1d00h50m         2057     2119 ASIC0
3.3.3.42        4      65100     29882     29988        0    0    0 1d00h50m          133     2119 ixre-egl-board182-AS
3.3.3.44        4      65100     29912     29990        0    0    0 1d00h50m          134     2119 ixre-egl-board182-AS

How did you do it?

• While removing new bgp neighbor config, make sure it is removed only for the specific asic under test.

How did you verify/test it?

• Ran all the above-mentioned test case on a T2 multi-asic chassis and made sure test passed with expected behavior.

Any platform specific information?

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

Documentation

[cyw233]

Great catch @sanjair-git! I'm wondering why I didn't see this behavior on Cisco 8000. Maybe it's because different platforms have different mechanisms when updating bgp neighbor status? May I ask what platforms you are using please?

[cyw233]

Can we move the above logging.debug(...) under this if statement as well, please? Maybe add the asic namespace in the this log too, e.g. "update CONFIG_DB admin_status to down on {namespace}". Thanks!

[sanjair-git]

Hi @cyw233, updated the logging as suggested. Please take a look.

[sanjair-git]

Great catch @sanjair-git! I'm wondering why I didn't see this behavior on Cisco 8000. Maybe it's because different platforms have different mechanisms when updating bgp neighbor status? May I ask what platforms you are using please?

Hi @cyw233, Thanks for reviewing the code. We are using 'Nokia-IXR7250E-36x400G' T2 Chassis.

[cyw233]

Great catch @sanjair-git! I'm wondering why I didn't see this behavior on Cisco 8000. Maybe it's because different platforms have different mechanisms when updating bgp neighbor status? May I ask what platforms you are using please?

Hi @cyw233, Thanks for reviewing the code. We are using 'Nokia-IXR7250E-36x400G' T2 Chassis.

Hi @sanjair-git, thanks for the info! PR looks good, will approve once the PR checks succeed

[yejianquan]

LGTM

[mssonicbld]

Cherry-pick PR to 202405: #14315