-
Notifications
You must be signed in to change notification settings - Fork 388
bgp: T7760: remove per vrf instance system-as node #4684
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
Conversation
👍 |
✅ No issues found in unused-imports check.. Please refer the workflow run |
0e800f1
to
20a4de7
Compare
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
20a4de7
to
2781519
Compare
Conflicts have been resolved. A maintainer will review the pull request shortly. |
Originating from the bug in T7665. To avoid potential issues down the line - and given that there's no compelling technical reason to retain the system-as CLI node under per-VRF BGP configuration, which cannot be achieved through alternative means - the maintainers have collectively decided to deprecate the following command: set vrf name <name> protocols bgp system-as <asn> Starting with VyOS 1.4.4, this CLI command will be considered deprecated. While it will still be accepted, it will no longer have any operational effect. A deprecation warning will be displayed at commit time, indicating that the BGP ASN from the global BGP configuration is now used instead. A migration script will handle the transition and perform the following actions: * Ensure a global BGP configuration exists; if not, initialize one. * Iterate over all configured VRFs to determine whether a BGP instance exists * For any insance, update the configuration to use the global system-as and apply the local-as ASN no-prepend replace-as option on all affected neighbors to preserve existing behavior. * If a neighbor is already configured with a local-as directive, that neighbor will be excluded from the migration process, as it already follows a custom configuration. * Add allowas-in per neighbor option. Required to not deny prefix received updates due to as-path contains our own global ASN.
VyOS 1.5 and onwards will no longer have the following CLI node available: set vrf name <name> protocols bgp system-as <asn>
2781519
to
85fe32f
Compare
CI integration 👍 passed! Details
|
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.
The issue is real and I see no other solution. The migration script and everything else look good to me.
There could be a case for per VRF
Check
Check BGP table:
Will it be impossible to do it after this change? |
Your config
Will be migrated to:
Yes - you can always adjust an AS path with a route-map and replace ASNs as much as you like |
@aapostoliuk, could you take a look at whether we have some similar configs that could be affected? Or are you OK with those changes? |
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.
Delete system-as under VRF to avoid bugs with not loaded configuration after reboot.
Change summary
Originating from the bug in T7665. To avoid potential issues down the line - and given that there's no compelling technical reason to retain the system-as CLI node under per-VRF BGP configuration, which cannot be achieved through alternative means - the maintainers have collectively decided to deprecate the following command:
set vrf name <name> protocols bgp system-as <asn>
Starting with VyOS 1.4.4, this CLI command will be considered deprecated. While it will still be accepted, it will no longer have any operational effect. A deprecation warning will be displayed at commit time, indicating that the BGP ASN from the global BGP configuration is now used instead.
A migration script will handle the transition and perform the following actions:
and apply the local-as ASN no-prepend replace-as option on all affected
neighbors to preserve existing behavior.
will be excluded from the migration process, as it already follows a custom
configuration.
The following migration takes place - verified by smoketests
Types of changes
Related Task(s)
Related PR(s)
How to test / Smoketest result
Checklist: