Skip to content
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

[test gap] Test gap to cover advertising through network command in BGP #14683

Merged

Conversation

siqbal1986
Copy link
Contributor

@siqbal1986 siqbal1986 commented Sep 20, 2024

Description of PR

Summary:
Fixes # (issue)
#10837

Orignal Problem
In multipath scenario when a route is advertised through network command from two neighbors, only one path is chosen. Doing clear bgp * recovers the device from this scenario.

If the same route (be it default or non-default) is advertised from two leaf to a ToR, the leaf initially shows only one leaf's links as next hop. When we do clear bgp *, it is then updated.

B>* 20.0.0.1/32 [20/0] via 192.168.1.2, PortChannel1, weight 1, 00:16:52

               via 192.168.2.2, PortChannel2, weight 1, 00:16:52
               via 192.168.3.2, PortChannel3, weight 1, 00:16:52
               via 192.168.4.2, PortChannel4, weight 1, 00:16:52
After doing clear bgp * in tgn-sonic-n2-t1 I can see this

B>* 20.0.0.1/32 [20/0] via 192.168.1.2, PortChannel1, weight 1, 00:00:02

               via 192.168.2.2, PortChannel2, weight 1, 00:00:02
               via 192.168.3.2, PortChannel3, weight 1, 00:00:02
               via 192.168.4.2, PortChannel4, weight 1, 00:00:02
               via 192.168.5.2, PortChannel5, weight 1, 00:00:02
               via 192.168.6.2, PortChannel6, weight 1, 00:00:02
               via 192.168.8.2, PortChannel8, weight 1, 00:00:02

This issue was fixed in PR sonic-net/sonic-buildimage#17184
However a test for this was missing.
so this test adds a prefix on 2 T1 neighbors using network command and checks if the advertised route is learnt on the T0 DUT

Type of change

Added anew test

  • 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?

advertising through network command might result in issue sonic-net/sonic-buildimage#17183.

How did you do it?

Add same route on 2 T1 neighbors of a TOR and advertise them. Then check on the DUT the routes are learnt and added to ROUTE_TABLE.

How did you verify/test it?

image

Any platform specific information?

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

T0 and Vs

Documentation

@prsunny
Copy link
Contributor

prsunny commented Sep 23, 2024

@dgsudharsan for viz

@prsunny
Copy link
Contributor

prsunny commented Sep 23, 2024

@siqbal1986 , can you please provide description on the steps and expected result? Initially i thought its a T1 test but your test topology mentions t0 and vs.

@siqbal1986
Copy link
Contributor Author

siqbal1986 commented Oct 4, 2024

@prsunny I have updated the Description.

Copy link
Collaborator

@StormLiangMS StormLiangMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@StormLiangMS StormLiangMS merged commit d24042b into sonic-net:master Oct 23, 2024
16 checks passed
sreejithsreekumaran pushed a commit to sreejithsreekumaran/sonic-mgmt that referenced this pull request Nov 15, 2024
…the TOR (sonic-net#14683)

Description of PR
Summary:
Fixes # (issue)
sonic-net#10837

Orignal Problem
In multipath scenario when a route is advertised through network command from two neighbors, only one path is chosen. Doing clear bgp * recovers the device from this scenario.

If the same route (be it default or non-default) is advertised from two leaf to a ToR, the leaf initially shows only one leaf's links as next hop. When we do clear bgp *, it is then updated.

B>* 20.0.0.1/32 [20/0] via 192.168.1.2, PortChannel1, weight 1, 00:16:52

               via 192.168.2.2, PortChannel2, weight 1, 00:16:52
               via 192.168.3.2, PortChannel3, weight 1, 00:16:52
               via 192.168.4.2, PortChannel4, weight 1, 00:16:52
After doing clear bgp * in tgn-sonic-n2-t1 I can see this

B>* 20.0.0.1/32 [20/0] via 192.168.1.2, PortChannel1, weight 1, 00:00:02

               via 192.168.2.2, PortChannel2, weight 1, 00:00:02
               via 192.168.3.2, PortChannel3, weight 1, 00:00:02
               via 192.168.4.2, PortChannel4, weight 1, 00:00:02
               via 192.168.5.2, PortChannel5, weight 1, 00:00:02
               via 192.168.6.2, PortChannel6, weight 1, 00:00:02
               via 192.168.8.2, PortChannel8, weight 1, 00:00:02

This issue was fixed in PR sonic-net/sonic-buildimage#17184
However a test for this was missing.
so this test adds a prefix on 2 T1 neighbors using network command and checks if the advertised route is learnt on the T0 DUT
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.

3 participants