[snaragund]

• RT-1.25: wait for IPv4 and IPv6 ARP after StartProtocols before traffic.
• RT-3.1: on KNE, send 500 pps for 15s instead of 5% line rate for one minute. Hardware behavior is unchanged.
• RT-7.2: on KNE, wait for permit prefixes in the AFT before traffic. Also wait for ARP and for the OTG BGP session to be established.
• SFLOW-1: use the DUT loopback as the KNE sFlow source address, and treat ixr10e as a KNE model.
• TE-3.7: reduce the traffic rate from 100000 to 10000 pps.Hardware behavior is unchanged.
• Add internal/kneutil.IsKNEBinding so KNE-only behavior stays off the hardware path.

"This code is a Contribution to the OpenConfig Feature Profiles project ("Work") made under the Google Software Grant and Corporate Contributor License Agreement ("CLA") and governed by the Apache License 2.0. No other rights or licenses in or to any of Nokia's intellectual property are granted for any other purpose. This code is provided on an "as is" basis without any warranties of any kind."

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces infrastructure and test-specific adjustments to improve compatibility and reliability for KNE (Kubernetes Network Emulation) environments. By implementing a mechanism to distinguish between KNE and hardware bindings, the changes allow for targeted test tweaks—such as synchronization waits and rate adjustments—without impacting the baseline behavior of hardware-based tests.

Highlights

• KNE-specific test adjustments: Introduced internal/kneutil.IsKNEBinding to gate KNE-only test behaviors, ensuring hardware test paths remain unaffected.
• Protocol and Traffic synchronization: Updated multiple tests to wait for ARP resolution, BGP session establishment, and AFT prefix presence before initiating traffic, improving test stability on KNE.
• Performance and Configuration tuning: Adjusted traffic rates and durations for KNE environments (e.g., 500 pps for 15s) and updated sFlow source addresses and device models.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[OpenConfigBot]

Pull Request Functional Test Report for #6149 / 1b16c25

Virtual Devices

Device	Test	Status	Test Documentation	Job	Raw Log
Arista cEOS		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Cisco 8000E		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Cisco XRd		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Juniper ncPTX		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Nokia SR Linux		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Openconfig Lemming		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route

Hardware Devices

Device	Test	Status	Test Documentation	Raw Log
Arista		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Cisco		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Juniper		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route
Nokia		RT-7.2: pending authorization TE-3.7: pending authorization RT-3.1: pending authorization SFLOW-1: pending authorization RT-1.25: pending authorization	RT-7.2: BGP Policy Community Set TE-3.7: Base Hierarchical NHG Update RT-3.1: Policy based VRF selection SFLOW-1: sFlow Configuration and Sampling RT-1.25: Management network-instance default static route

Help

[gemini-code-assist]

Code Review

This pull request introduces a new kneutil package to support KNE-specific test behaviors, updating several OTG tests (BGP community, VRF selection, sFlow, and static route) to dynamically adjust traffic flow rates, durations, and wait times when running on KNE. Additionally, it ensures proper neighbor resolution by adding WaitForARP calls before starting traffic. The review feedback suggests adding a defensive nil check for the dut pointer in the new IsKNEBinding function to prevent potential runtime panics.

[navaneethyv]

Can you clarify how this works ?

[snaragund]

• IsKNEBinding checks whether the DUT’s Ondatra binding implements knebind’s KNE Service(name) (*topo.Service, error) API via binding.DUTAs(dut.RawAPIs().BindingDUT(), &lookup). That API exists on knebind’s ServiceDUT (built from the KNE topology services map) and not on featureprofiles’ staticDUT used for HW/static binding. We gate on Vendor()==NOKIA because these tweaks are Nokia KNE–specific as of now(other vendors can use if required).
• Challenges of kneDeviceModelList:
  • kneDeviceModelList differentiate KNE/Hw only based on model, which is not safe proxy for virtual model because down the line model can/may be same in future for both Hw/KNE.
  • Using kneDeviceModelList forces to use same change across all vendors, which if needed different changes then it will not be applicable.
• IsKNEBinding resolves above both challenges & it is implemented in RT-3.1/RT-7.2 for reference.

[navaneethyv]

openconfig/ondatra#158 would this make it simpler ?