Traffic Blackhole on gRIBI Invalid Next-Hop (Strict FIB Precedence) - #5993
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! 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 a new system test plan designed to verify device-level hardware adherence to controller routing intent via gRIBI. The primary goal is to ensure that when a specific gRIBI tunnel next-hop is disabled, the device correctly blackholes the traffic rather than reverting to less-specific BGP underlay routes. This validates that controller-programmed routing intent takes precedence over default hardware behaviors. Highlights
Using Gemini Code AssistThe 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
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 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
|
There was a problem hiding this comment.
Code Review
This pull request introduces a new test plan (TE-1.22) to validate traffic blackholing on gRIBI invalid next-hops under strict FIB precedence, adding a detailed README, metadata, and registering the test. The review feedback correctly identifies style guide violations and mathematical errors in the IPv4 prefix definitions within the test plan, specifically pointing out the use of disallowed IP blocks, incorrect subnetting logic for generating 1,000 distinct prefixes, and a typo in a destination IP address. The reviewer provided actionable suggestions to use the compliant 100.64.0.0/10 block and vary the second and third octets instead.
100928e to
73f257d
Compare
System Test Plan see for more info: b/540867175