feat: Add TE-6.5 Community-based dynamic route-leaking between VRFs FNT requirements#5449
feat: Add TE-6.5 Community-based dynamic route-leaking between VRFs FNT requirements#5449mellowdrifter wants to merge 7 commits into
Conversation
Pull Request Functional Test Report for #5449 / f13cdacVirtual Devices
Hardware Devices
|
…d generic communities to prevent leaks
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 the formal FNT requirements for the TE-6.5 test case, covering the validation of dynamic route-leaking between VRFs based on BGP communities. It also includes a broad update to the project's test registry, adding new test definitions and cleaning up existing entries to ensure accurate tracking of feature profiles. 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
|
…ial withdrawal verification test cases
![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 introduces a new test plan (TE-6.5) for community-based dynamic route-leaking between VRFs, including its documentation and metadata. Additionally, it performs a significant update to the test registry, adding numerous new test entries across various features and cleaning up existing entries by removing empty execution fields and reordering tests. The review feedback correctly identifies several violations of the repository's style guide regarding network assignments in the new documentation; specifically, the test plan should use RFC 5398 for ASNs and RFC 5737 for IPv4 prefixes.
| * Global BGP session between DUT:Port1 (AS 65003) and ATE:Port1 (AS 65001). | ||
| * BGP session in `URPF` VRF between DUT:Port2 (AS 65003) and ATE:Port2 (AS 65002). |
There was a problem hiding this comment.
The ASNs used for the BGP sessions (65001, 65002, 65003) do not adhere to the repository's guidelines for documentation ASNs. Please use values from the RFC 5398 blocks as specified in the style guide.
| * Global BGP session between DUT:Port1 (AS 65003) and ATE:Port1 (AS 65001). | |
| * BGP session in `URPF` VRF between DUT:Port2 (AS 65003) and ATE:Port2 (AS 65002). | |
| * Global BGP session between DUT:Port1 (AS 65536) and ATE:Port1 (AS 64496). | |
| * BGP session in URPF VRF between DUT:Port2 (AS 65536) and ATE:Port2 (AS 64497). |
References
- ASNs should use RFC 5398 documentation blocks (64496-64511 or 65536-65551). (link)
| * **Session 1**: ATE:Port1 (AS 65001) peers to DUT:Port1. | ||
| * **Session 2**: ATE:Port2 (AS 65002) peers to DUT:Port2. |
There was a problem hiding this comment.
The ASNs used in the ATE configuration should be consistent with the documentation ASN requirements and match the DUT configuration peering sessions.
| * **Session 1**: ATE:Port1 (AS 65001) peers to DUT:Port1. | |
| * **Session 2**: ATE:Port2 (AS 65002) peers to DUT:Port2. | |
| * Session 1: ATE:Port1 (AS 64496) peers to DUT:Port1. | |
| * Session 2: ATE:Port2 (AS 64497) peers to DUT:Port2. |
References
- ASNs should use RFC 5398 documentation blocks (64496-64511 or 65536-65551). (link)
|
|
||
| #### TE-6.5.1: Dynamic Route Leak on BGP Community Match | ||
|
|
||
| 1. From ATE:Port1, advertise a list of prefixes (e.g., `100.1.1.0/24` and `2001:db8:1::/48`) containing one of the matching communities (e.g., `64500:10100`). |
There was a problem hiding this comment.
The IPv4 prefix 100.1.1.0/24 is not within the allowed documentation or shared address blocks specified in the style guide. Please use an RFC 5737 block instead.
| 1. From ATE:Port1, advertise a list of prefixes (e.g., `100.1.1.0/24` and `2001:db8:1::/48`) containing one of the matching communities (e.g., `64500:10100`). | |
| 1. From ATE:Port1, advertise a list of prefixes (e.g., 192.0.2.0/24 and 2001:db8:1::/48) containing one of the matching communities (e.g., 65532:10100). |
References
- IPv4 assignments should 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. (link)
|
|
||
| #### TE-6.5.2: No Route Leak on Community Absence | ||
|
|
||
| 1. From ATE:Port1, advertise a new list of prefixes (e.g., `100.2.2.0/24` and `2001:db8:2::/48`) containing either *no communities* or a non-matching community (e.g., `64500:9999`). |
There was a problem hiding this comment.
The IPv4 prefix 100.2.2.0/24 does not adhere to the repository's network assignment guidelines. Please use a prefix from the RFC 5737 blocks.
| 1. From ATE:Port1, advertise a new list of prefixes (e.g., `100.2.2.0/24` and `2001:db8:2::/48`) containing either *no communities* or a non-matching community (e.g., `64500:9999`). | |
| 1. From ATE:Port1, advertise a new list of prefixes (e.g., 198.51.100.0/24 and 2001:db8:2::/48) containing either no communities or a non-matching community (e.g., 65532:9999). |
References
- IPv4 assignments should 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. (link)
…TEST-NET address blocks to prevent style guide violations
…to fix CI check failures
…mod' to support Go 1.25.0 upgrades
2 participants
Adding FNT requirements README, metadata, and registry entry for TE-6.5. This is a pure FNT requirements design change.