-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
T5931: Add option to append route-target when adding additional imports #3623
Conversation
Added leafNode type /multi for VPN route-targets Updated bgpd.frr.j2 to handle list input for route-targets
Added leafNode type /multi for VPN route-targets Updated bgpd.frr.j2 to handle list input for route-targets
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CLI syntax changed and a migration script is required
set vrf name Admins protocols bgp address-family ipv4-unicast route-target vpn import '1:1 1:2'
The configuration needs to be checked to see if several imports are used before changes and migrating to the new format.
A request was made to allow both to be used. If both of these are allowed, then there's no need for any migration:
This creates the following for the FRR config:
I think allowing both makes sense. This would provide familiarity for people coming from other products, but maintain familiarity for those that have been using VyOS/FRR. |
@l0crian1 Do you test when both are equal (import/export) and add different import ? |
@fett0 Do you mean like this?
If so, that works completely fine.
If you meant something like this:
That'll already throw an error since both is prevented from existing alongside either import or export. |
Exactly ! yes , we've had some problems with those combinations in the past , not all the combinations are possible on FRR and for that reason , that was my question . I like the idea that you propose in this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A request was made to allow both to be used. If both of these are allowed, then there's no need for any migration:
I'd recommend not to use both "styles" as this will lead to a validation hell and also is unintuitive.
As 1.4 syntax is frozen this change will only make it into 1.5 and we should make it <multi/>
only and migrate existing configurations.
I'm wary to make that change if not allowing both. The current syntax has existed for 3 years, and if it'll only make it into 1.5, it could be another 3 years before that is LTS. So that is potentially 3-6 years of user created tools that would need to be refactored when they move to 1.5. Could lead to a lot of customer unhappiness in the future. |
Change to the correct format; we won't accept both formats
Unexpected format:
Also, the migration script must check if several values are used. |
Going to close this PR for now. The functionality for multiple route-targets already exists, so I worry this change will create more problems in the future than it solves right now. |
This PR adds the ability to have multiple import/export lines of route-target configs within the VPN address-family.
Change Summary
Types of changes
Related Task(s)
https://vyos.dev/T5931
Related PR(s)
Component(s) name
frr, bdgd
Proposed changes
How to test
Prior to the change, you could only configure a single import or export line. This required you to place the route-targets in a space separated string:
After the change, you can have those on a single line. This logic more falls in line with industry standards when configuring route-targets:
Verification can be performed within FRR:
Configurations that contain space separated values can still exist alongside the additional config:
Smoketest result
Checklist: