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

[fib] Fix incorrect prefix/nh list generation for single_asic device #3352

Merged
merged 1 commit into from
May 6, 2021

Conversation

vcheketx
Copy link
Contributor

Description of PR

Summary:
Fixes test_basic_fib failing due to incorrect fib_info generation on single_asic devices.

Type of change

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

Approach

What is the motivation for this PR?

PR 3214 introduced multi-asic support for fib test.
test_basic_fib fails on single-asic devices with the following error:
"AssertionError: Received expected packet on port 13 for device 0, but it should have arrived on one of these ports: [28, 29, 30, 31].

This occurs due to prefixes for directly connected subnets not being added to fib_info_file.
E.g. we have following entry on DUT:

  "ROUTE_TABLE:192.168.0.0/21": {
    "expireat": 1618578926.178756, 
    "ttl": -0.001, 
    "type": "hash", 
    "value": {
      "ifname": "Vlan1000", 
      "nexthop": "0.0.0.0"
    }
  }

Previously, we added entry for 192.168.0.0/21 to fib_info with nexthop '[]' and skipped this range later during the test.
Now this entry is skipped from the start and not added to fib_info.
This results in IP range for subnet 192.168.0.0/21 (or any other directly connected subnet) being considered a part of IP range for previous subnet:
Expected IP range:

169.255.0.0 - 192.167.255.255
192.168.0.0 - 192.168.7.255
192.168.8.0 - 192.168.8.127

Actual IP range:

169.255.0.0 - 192.168.7.255
192.168.8.0 - 192.168.8.127

How did you do it?

For single-asic devices, skipped prefixes are now added to fib_info file with nexthop '[]'.

How did you verify/test it?

Run test_basic_fib

Any platform specific information?

SONiC Software Version: SONiC.master.173-dirty-20210412.032545
Distribution: Debian 10.9
Kernel: 4.19.0-12-2-amd64
Build commit: 7df4c0ad
Build date: Mon Apr 12 10:15:05 UTC 2021
Platform: x86_64-accton_wedge100bf_32x-r0
HwSKU: montara

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

Documentation

@vcheketx vcheketx requested a review from a team as a code owner April 16, 2021 16:17
@wangxin
Copy link
Collaborator

wangxin commented May 6, 2021

LGTM. Thanks for the investigation and fix!

@wangxin wangxin merged commit 2f655ce into sonic-net:master May 6, 2021
@vcheketx
Copy link
Contributor Author

vcheketx commented May 6, 2021

LGTM. Thanks for the investigation and fix!

@wangxin Thank you!

bingwang-ms pushed a commit to bingwang-ms/sonic-mgmt that referenced this pull request Aug 18, 2021
We are migrating from Jenkins to azure pipeline. This PR added azure pipeline yaml files and dependent template files for nightly tests. Pipeline yaml files only added for 3 testbeds yet. The pipelines were originally added to branch azp-test of repo https://dev.azure.com/mssonic/internal/_git/sonic-mgmt-int. They have been tested on Azure DevOps.

Now we formally add these pipelines to the Networking-acs-sonic-mgmt repo. Currently the internal branch of Networking-acs-sonic-mgmt is synched to same internal branch of the sonic-mgmt-int repo. After this PR is merged, we need to update configuration of the created pipelines to formally use these files from the internal branch.

If the pipelines work fine with yaml files from internal branch, we will create more pipeline files based on current templates for rest of the nightly testbeds.

Related work items: sonic-net#3021, sonic-net#3073, sonic-net#3135, sonic-net#3153, sonic-net#3162, sonic-net#3176, sonic-net#3238, sonic-net#3241, sonic-net#3346, sonic-net#3352, sonic-net#3378, sonic-net#3389, sonic-net#3395, sonic-net#3397, sonic-net#3398, sonic-net#3407, sonic-net#3410, sonic-net#3411, sonic-net#3412, sonic-net#3413, sonic-net#3414, sonic-net#3415, sonic-net#3434, sonic-net#3437, sonic-net#3445, sonic-net#3446, sonic-net#3447, #9740131, #9821349
vmittal-msft pushed a commit to vmittal-msft/sonic-mgmt that referenced this pull request Sep 28, 2021
…-net#3352)

What is the motivation for this PR?
PR 3214 introduced multi-asic support for fib test.
test_basic_fib fails on single-asic devices with the following error:
"AssertionError: Received expected packet on port 13 for device 0, but it should have arrived on one of these ports: [28, 29, 30, 31].

This occurs due to prefixes for directly connected subnets not being added to fib_info_file.
E.g. we have following entry on DUT:
  "ROUTE_TABLE:192.168.0.0/21": {
    "expireat": 1618578926.178756, 
    "ttl": -0.001, 
    "type": "hash", 
    "value": {
      "ifname": "Vlan1000", 
      "nexthop": "0.0.0.0"
    }
  }

Previously, we added entry for 192.168.0.0/21 to fib_info with nexthop '[]' and skipped this range later during the test.
Now this entry is skipped from the start and not added to fib_info.
This results in IP range for subnet 192.168.0.0/21 (or any other directly connected subnet) being considered a part of IP range for previous subnet:

Expected IP range:
169.255.0.0 - 192.167.255.255
192.168.0.0 - 192.168.7.255
192.168.8.0 - 192.168.8.127

Actual IP range:
169.255.0.0 - 192.168.7.255
192.168.8.0 - 192.168.8.127

How did you do it?
For single-asic devices, skipped prefixes are now added to fib_info file with nexthop '[]'.

How did you verify/test it?
Run test_basic_fib
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.

2 participants