-
Notifications
You must be signed in to change notification settings - Fork 146
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
Adding AFT Base cases #3506
base: main
Are you sure you want to change the base?
Adding AFT Base cases #3506
Conversation
Pull Request Test Coverage Report for Build 11360029682Details
💛 - Coveralls |
@ElodinLaarz can you review please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a first pass on the READMEs. Thanks for writing these up :)
* IS-IS must be level 2 only with wide metric. | ||
* IS-IS must be point to point. | ||
* Send 1000 ipv4 and 1000 ipv6 IS-IS prefixes from ATE:port3 to DUT:port3. | ||
* IS-IS must be up and running, prefixes must be in RIB and FIB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the proposed method of confirming the values are in the RIB and FIB using the provided paths?
(Same question in the other README.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The README should be precise in how the validation is performed. (if the go test code was included, we could use the code to review the most specific options. You are welcome to include the code and the readme in the same PR).
For example, we use gnmi subscribe with ON_CHANGE option. So the subscription should start before advertising prefixes.
* IS-IS must be up and running, prefixes must be in RIB and FIB. | |
* Use gnmi Subscribe with ON_CHANGE option to /network-instances/network-instance/afts | |
* Advertise 1,000 ipv4,ipv6 prefixes from ATE port1, port2 | |
* Verify afts prefix entries using the folllowing paths within a timeout period of 10 seconds | |
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/origin-protocol
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/prefix
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/origin-protocol
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/counters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, I don't see the recommended paths to be verified in this section as requested?
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/origin-protocol
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/prefix
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/origin-protocol
* Advertise 1000 ipv4,ipv6 prefixes from ATE port1,port2 observe received prefixes at DUT. | ||
* Validate total number of entries of AFT for IPv4 and IPv6. | ||
* Each prefix must have 2 next hops pointing to ATE port1,port2. | ||
* Advertise 100 ipv4,ipv6 from ATE port3 observe received prefixes at DUT. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the hope here? Are we testing gNMI updates here? Should we be concurrently handling a gRPC stream with a subscription (ON_CHANGE, for example) to make sure we get these 100 prefixes in addition to the previous 1,000?
Or should this be in the next section where we would like these to be the destination at the end of the tunnels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explicitly list out which of the options I suggested you are doing here?
|
||
/network-instances/network-instance/afts/ethernet/mac-entry/state/next-hop-group: | ||
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/next-hop-group: | ||
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/origin-protocol: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a little comment to the verification where we check the origin-protocol for the advertised prefixes, if we're including it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added verifications pointing towards this path.
/network-instances/network-instance/afts/next-hops/next-hop/state/ip-address: | ||
/network-instances/network-instance/afts/next-hops/next-hop/state/mac-address: | ||
/network-instances/network-instance/afts/next-hops/next-hop/state/origin-protocol: | ||
/network-instances/network-instance/afts/state-synced/state/ipv4-unicast: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we call out these state-synced
leaves as being tested here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kindly clarify
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not see which test above checked this path. Could you mention how it's being used?
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/entry-metadata: | ||
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/next-hop-group-network-instance: | ||
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/origin-network-instance: | ||
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/prefix: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, these non-state paths are not needed, as the telemetry verification occurs on the already present state paths /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
didnt follow please clarify
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mentioned in the other comment, but since this is not a state
path it can be removed.
* IS-IS must be level 2 only with wide metric. | ||
* IS-IS must be point to point. | ||
* Send 1000 ipv4 and 1000 ipv6 IS-IS prefixes from ATE:port1 to DUT:port1. | ||
* IS-IS must be up and running, prefixes must be in RIB and FIB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question-- what is the intended means to verify this you were thinking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It still says the same as before?
* IS-IS must be up and running, prefixes must be in RIB and FIB.
(which is not what we want to say here.)
But I do see you updated the other README. Can we update this one as well?
|
||
## AFT-2.1.1: AFT Prefix Counters ipv4 packets forwarded, IS-IS route. | ||
|
||
From ATE:port2 send 10000 pps to one of the ipv4 prefix advertise by IS-IS, after 1 minute stop the traffic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potentially, we can replace this "1 minute of traffic" with a certain number of packets sent (e.g. send 100k, etc.)? This can save time in the test and make it a bit more consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
* IS-IS routes advertised from ATE:port1 must have one next hop. | ||
|
||
|
||
## AFT-2.1.1: AFT Prefix Counters ipv4 packets forwarded, IS-IS route. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor, optional comment-- since you're sending packets and then waiting a bunch for the packets to be sent, to minimize runtime of the test, you can group the checks (check packets and octets in the same test), and send a fixed number of packets, instead of waiting for a fixed amount of time.
Then, you can subscribe to the data and make sure it updates within a prescribed amount of time after the packets have been sent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for debugging purpose and avoid complication. I want to keep it as 2 different cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that is okay if we replace the sleep/wait with sending a fixed number of packets, I think.
|
||
IPv4/IPv6 unicast routes next hop group and next hop. | ||
|
||
## Procedure |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Name this heading ## Test setup`` and add a sub-heading for
### Generate DUT configuration`. Place the description of the DUT and ATE configurations you want generated there.
The test procedure should have a gnmi.Set with REPLACE option to push the config to the DUT.
(The ATE config push can be in the test setup or in the test procedure, whatever works best for your use case)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
* IS-IS must be level 2 only with wide metric. | ||
* IS-IS must be point to point. | ||
* Send 1000 ipv4 and 1000 ipv6 IS-IS prefixes from ATE:port3 to DUT:port3. | ||
* IS-IS must be up and running, prefixes must be in RIB and FIB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The README should be precise in how the validation is performed. (if the go test code was included, we could use the code to review the most specific options. You are welcome to include the code and the readme in the same PR).
For example, we use gnmi subscribe with ON_CHANGE option. So the subscription should start before advertising prefixes.
* IS-IS must be up and running, prefixes must be in RIB and FIB. | |
* Use gnmi Subscribe with ON_CHANGE option to /network-instances/network-instance/afts | |
* Advertise 1,000 ipv4,ipv6 prefixes from ATE port1, port2 | |
* Verify afts prefix entries using the folllowing paths within a timeout period of 10 seconds | |
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix
/network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/origin-protocol
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/prefix
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/origin-protocol
/network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/counters
IPv4/IPv6 unicast routes next hop group and next hop. | ||
|
||
## Procedure | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you have tests here, declare a subtest heading like:
## AFT-1.1.1: AFT ipv4/6 unicast entries
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
IPv4/IPv6 unicast routes next hop group and next hop. | ||
|
||
## Procedure | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you have tests here, declare a subtest heading like:
## AFT-1.1.1: AFT ipv4/6 unicast entries
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
didnt follow, it is separated isnt it?
This includes the test cases for validating AFT Base path.