Enhance README with BGP and static route tests#5540
Conversation
Added verification steps for BGP and static route redistribution persistence after process restart, including traffic validation and configuration parameters.
Pull Request Functional Test Report for #5540 / 6f72969Virtual Devices
Hardware Devices
|
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 enhances the existing documentation for BGP and IS-IS redistribution tests. It introduces a detailed procedure for verifying that redistributed routes remain persistent following a process restart on the device under test, ensuring traffic continuity and correct routing table state. 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a new test procedure to verify BGP and Static redistribution persistence after a process restart, including a Canonical OC JSON configuration and updated parameter coverage paths. The reviewer correctly identified that the proposed IPv4 prefixes (192.168.10.0/25 and 192.168.10.0/28) violate the repository style guide, which restricts the use of common local private ranges. These should be updated to use RFC 5737 compliant blocks as suggested.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| * Configure a static route on the DUT for IPv4 prefix ```192.168.10.0/25``` | ||
| with the next-hop set to ATE port-2. | ||
| * /network-instances/network-instance/protocols/protocol/static-routes/static/config/prefix | ||
| * Advertise a more-specific IPv4 prefix ```192.168.10.0/28``` via BGP from | ||
| ATE port-1, ensuring the route resolves to the same next-hop as the | ||
| static route. | ||
| * Configure source protocol ```STATIC``` to be redistributed to ```ISIS```. | ||
| * /network-instances/network-instance/table-connections/table-connection/config/src-protocol | ||
| * Verify on the ATE that both prefixes (```192.168.10.0/25``` from Static | ||
| and ```192.168.10.0/28``` from BGP) are received and present in the | ||
| IS-IS link-state database. | ||
| * /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/extended-ipv4-reachability/prefixes/prefix/state/prefix | ||
| * /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/extended-ipv4-reachability/prefixes/prefix/state/metric | ||
| * Restart the routing process on the DUT (e.g., via gNOI or system reboot). | ||
| * Wait for the BGP and IS-IS sessions to fully reconverge. | ||
| * Validate that the IS-IS on ATE still receives both the redistributed | ||
| Static prefix (```192.168.10.0/25```) and the redistributed BGP prefix | ||
| (```192.168.10.0/28```) without any loss. | ||
| * /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/extended-ipv4-reachability/prefixes/prefix/state/prefix | ||
| * Initiate traffic from ATE port-1 to the DUT destined to both prefixes | ||
| (```192.168.10.0/25``` and ```192.168.10.0/28```). | ||
| * Validate that the traffic is successfully received on ATE port-2. |
There was a problem hiding this comment.
The IPv4 prefixes 192.168.10.0/25 and 192.168.10.0/28 belong to the 192.168.0.0/16 range, which is a common local private range. According to the Repository Style Guide (lines 63-69), we must use RFC 5737 blocks (such as 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24) and avoid using common local private ranges like 192.168.0.0/16.
Please update these prefixes to use a compliant RFC 5737 block, such as 198.51.100.0/25 and 198.51.100.0/28.
* Configure a static route on the DUT for IPv4 prefix 198.51.100.0/25
with the next-hop set to ATE port-2.
* /network-instances/network-instance/protocols/protocol/static-routes/static/config/prefix
* Advertise a more-specific IPv4 prefix 198.51.100.0/28 via BGP from
ATE port-1, ensuring the route resolves to the same next-hop as the
static route.
* Configure source protocol STATIC to be redistributed to ISIS.
* /network-instances/network-instance/table-connections/table-connection/config/src-protocol
* Verify on the ATE that both prefixes (198.51.100.0/25 from Static
and 198.51.100.0/28 from BGP) are received and present in the
IS-IS link-state database.
* /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/extended-ipv4-reachability/prefixes/prefix/state/prefix
* /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/extended-ipv4-reachability/prefixes/prefix/state/metric
* Restart the routing process on the DUT (e.g., via gNOI or system reboot).
* Wait for the BGP and IS-IS sessions to fully reconverge.
* Validate that the IS-IS on ATE still receives both the redistributed
Static prefix (198.51.100.0/25) and the redistributed BGP prefix
(198.51.100.0/28) without any loss.
* /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/extended-ipv4-reachability/prefixes/prefix/state/prefix
* Initiate traffic from ATE port-1 to the DUT destined to both prefixes
(198.51.100.0/25 and 198.51.100.0/28).
* Validate that the traffic is successfully received on ATE port-2.References
- IPv4 network assignments must use RFC 5737 blocks (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) or 100.64.0.0/10, 198.18.0.0/15, and must not use common local private ranges like 192.168.0.0/16. (link)
| "prefix": "192.168.10.0/25", | ||
| "config": { | ||
| "prefix": "192.168.10.0/25" | ||
| }, | ||
| "next-hops": { | ||
| "next-hop": [ | ||
| { | ||
| "index": "0", | ||
| "config": { | ||
| "index": "0", | ||
| "next-hop": "192.168.10.1" | ||
| } | ||
| } |
There was a problem hiding this comment.
The Canonical OC JSON block also uses the non-compliant 192.168.10.0/25 prefix and 192.168.10.1 next-hop address. Please update these to match the compliant RFC 5737 block suggested above (e.g., 198.51.100.0/25 and 198.51.100.1).
| "prefix": "192.168.10.0/25", | |
| "config": { | |
| "prefix": "192.168.10.0/25" | |
| }, | |
| "next-hops": { | |
| "next-hop": [ | |
| { | |
| "index": "0", | |
| "config": { | |
| "index": "0", | |
| "next-hop": "192.168.10.1" | |
| } | |
| } | |
| "prefix": "198.51.100.0/25", | |
| "config": { | |
| "prefix": "198.51.100.0/25" | |
| }, | |
| "next-hops": { | |
| "next-hop": [ | |
| { | |
| "index": "0", | |
| "config": { | |
| "index": "0", | |
| "next-hop": "198.51.100.1" | |
| } | |
| } | |
| ] | |
| } |
References
- IPv4 network assignments must use RFC 5737 blocks (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) or 100.64.0.0/10, 198.18.0.0/15, and must not use common local private ranges like 192.168.0.0/16. (link)
Updated references from 'extended-ipv6-reachability' to 'ipv6-reachability' in test documentation for IS-IS redistribution.
2 participants
Added verification steps for BGP and static route redistribution persistence after process restart, including traffic validation and configuration parameters.