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

Add everflow test plan updated for egress acl and mirroring #3

Closed
wants to merge 2 commits into from

Conversation

wangxin
Copy link
Owner

@wangxin wangxin commented Jul 11, 2019

This test plan is based on https://github.com/Azure/SONiC/wiki/Everflow-test-plan

After sonic-net#411 and egress ACL are supported, the everflow testing need to be extended to cover these two new features.

The extended everflow testing also plan to cover IPv6.

A new ACL rule option "IN_PORTS" is added too.

Combinations | ACL table stage: ingress | ACL table stage: egress
-|-|-
ACL Rule MIRROR_INGRESS_ACTION | [x] | N/A
ACL Rule MIRROR_EGRESS_ACTION | [x] | [x]

Choose a reason for hiding this comment

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

For which platform is this table?

Copy link
Owner Author

Choose a reason for hiding this comment

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

This table listed all the possible combinations for all platforms. As you suggested, on a specific platform, we can query its SWITCH_CAPABILITY to decide which combinations to cover and skip unsupported combinations.

ACL Rule MIRROR_INGRESS_ACTION | [x] | N/A
ACL Rule MIRROR_EGRESS_ACTION | [x] | [x]

Totally there are 3 possible combinations. Not all the combinations are supported by all platforms. The actual combinations to be tested are determined the actual DUT platform.

Choose a reason for hiding this comment

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

I think of two options:

  1. Query SWITCH_CAPABILITY table and decide which test cases to run and which to skip
  2. Make user define this in some .yml configuration file per platform/hwsku/asic vendor

I am Ok with both. Since correctness of SWITCH_CAPABILITY table is verified by VS test I think you can rely on that during system level testing.
I am also Ok with .yml with configuration per platform/hwsku/asic.

Which one would you choose?

Copy link
Owner Author

Choose a reason for hiding this comment

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

I prefer option 1.

doc/acl/Everflow-test-plan.md Show resolved Hide resolved

Each test case will run traffic for persistent and dynamic Everflow ACL rules.

Each test case will analyze Everflow packet header and payload (if mirrored packet is equal to original).

Choose a reason for hiding this comment

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

In case of egress mirror are you planning to validate that this is indeed an egress mirrored packet?
e.g for simple case - routed packet ttl decremented? and on ingress tll is the same?

Copy link
Owner Author

Choose a reason for hiding this comment

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

I didn't think of that. But it is a very good idea. I'll update the test plan to add that validation.

- Send packets that matches each Everflow ACL rule.
- Verify that packet mirrored to appropriate port.
- Analyze mirrored packet header.
- Verify that mirrored packet payload is equal to sent packet.

Choose a reason for hiding this comment

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

What does it mean 'equal to sent packet'? It depends on ingress/egress stage. Please refer to above comment.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Sure, I'll update it to make it more accurate.

Copy link
Owner Author

Choose a reason for hiding this comment

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

The check here is for payload of mirrored packet. This part should always be equal to sent packet.

@liat-grozovik
Copy link

was this ever published with the test code?

@wangxin
Copy link
Owner Author

wangxin commented Jan 4, 2020

@liat-grozovik No, it was not published.
@stepanblyschak Since you have taken over implementing the testing, could you please confirm whether we can publish this to Azure? Or you can take over the test plan and publish it to Azure?

@wangxin wangxin closed this Dec 2, 2021
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