Issues with RT-5.1 test (Singleton Interface)

[mojiiba]

Hi, There are two issue with RT-5.1. Can u please help to resolve the issues.

• The test sets the MTU at the subinterface/ipv4 and ipv6 level (https://github.com/openconfig/featureprofiles/blob/d29b222f35ae6bf795ad667e08f67e63218ac9f6/feature/interface/singleton/ate_tests/singleton_test/singleton_test.go#L121) without setting the MTU for the physical interface. The MTU for the interface should be set to tc.MTU+14 (i.Mtu = ygot.Uint16(tc.mtu + 14)), otherwise the IPV4/6 should be dropped that will result in test failure.
• The test assumes that the number of output unicast packets from ATE that is captured at the flow level should be equal or larger than the number of inbound unicast packets by the DUT (https://github.com/openconfig/featureprofiles/blob/d29b222f35ae6bf795ad667e08f67e63218ac9f6/feature/interface/singleton/ate_tests/singleton_test/singleton_test.go#L337). This assumption is not correct due to 1- The flow statistics does not account for the control packets, but DUT's interface counter does account for it. 2- Also, ATE sends ICMPv6 since the ipv6 is configured on the ATE interface. Below figure shows that three control packet is received by the DUT that results in inbound packet to be larger than (+3) outbound packets.

To fix this issue, either we should have a threshold (+3) to account for the control packets or change the test logic to read the number of packets in a way to account for the control packets. I think ATE statistics at the port level account for control packets.

[earies]

@dplore @bstoll - I would suggest if any IP (or upper layer) MTU is being altered that a prerequisite would be to alter the interface MTU otherwise IP MTUs cannot be set. We should not introduce any internal implicit behaviors of treatment to the interface MTU if only an IP MTU is set but rather this should be explicit intent.

It is likely the YANG node descriptions for the mtu leafs should be updated to reflect this behavioral expectation as well

[liulk]

We did have a deviation for omitting/setting the L2 MTU some point in the past. I agree that devices that don't allow setting the L2 MTU is not fully compliant.

[liulk]

While #412 is intended to rectify a more precise language for the deviation, I want to explain how I interpret the OpenConfig MTU spec here.

• /interfaces/interface/config/mtu - Set the max transmission unit size in octets for the physical interface. If this is not set, the mtu is set to the operational default -- e.g., 1514 bytes on an Ethernet interface.
• /interfaces/interface/subinterfaces/subinterface/ipv4/config/mtu - The size, in octets, of the largest IPv4 packet that the interface will send and receive. The server may restrict the allowed values for this leaf, depending on the interface's type. If this leaf is not configured, the operationally used MTU depends on the interface's type.

So if we have these scenarios, this is how I interpret the OpenConfig compliance:

• Device A: enforces that L2 MTU >= L3 MTU and L2 MTU default is 1514. (compliant)
• Device B: allows L3 MTU to override L2 MTU. (also compliant)
• Device C: can only set L3 MTU but not L2 MTU (not compliant)

Is this something we can agree on?

[dplore]

IMO, the test should be modified to set both the L2 and L3 MTU to appropriate, compatible values. All compliant devices should allow setting of both these MTUs.

Agreed that scenario/device B scenario is compliant to the test requirements as they appear now. It is implementing behavior that is not prohibited and not specified by OpenConfig.

[liulk]

Hi Darren, if you could approve #412, then I'll send a follow up PR to add setting of L2 MTU as a deviation.

[dplore]

Done. IMO, L2 MTU should be the standard and if useful, we could add a deviation to disable of setting the L2 MTU.

If this doesn't sound right to you, we can discuss offline and see if/why it makes sense.

[liulk]

Sorry, I mean add the setting of L2 MTU, but add a deviation to omit the setting of L2 MTU.

[liulk]

Re: the second issue above "The test assumes that the number of output unicast packets from ATE that is captured at the flow level should be equal or larger than the number of inbound unicast packets"

Upon looking at this more closely, I agree that the direction of the less-than is an error. Fortunately, we've always had the ATE and DUT packet counters be equal at least for the unicast packets because I think the control packets tend to be broadcast, so that's why we didn't observe any test failures.

[agvarghe-cisco]

Still seeing the issue , ipv6 control packets is still not accounted for

singleton_test.go:356: ATE received too few destination packets: got 260906, want >= 260909

[liulk]

Are you sure this is not packet loss?

[mojiiba]

Yes, we are sure. If you notice the difference is only three packets (max six packets depending on the execution time of the test). We did the packet capture and the differences matches with the control packets (ipv6 neighborliness advertisement generated by ixia). We also do not see this issue when we do not configure ipv6 (we could pass the test for ipv4 cases).