bgp: remove per vrf instance system-as node
Closed, ResolvedPublicBUG
Actions

Assigned To

Authored By

	c-po
	Aug 28 2025, 7:03 AM

Description

Originating from the bug in T7665 https://vyos.dev/T7665#233659

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 and whether its system-as value differs from the global system-as.
For any mismatches, update the VRF BGP instance 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.

Details

Version: 1.4.3
Is it a breaking change?: Unspecified (possibly destroys the router)
Issue type: Bug (incorrect behavior)

Related Objects
Search...

Status	Subtype	Assigned	Task
Resolved	BUG	c-po	T7665 Commit failed when attempted to create a new BGP instance for VRF linked with VXLAN(L3VNI).
Resolved	BUG	c-po	T7760 bgp: remove per vrf instance system-as node
Resolved	BUG	c-po	T7904 BGP route reflector configuration broken due to T7760

Event Timeline

c-po created this task.Aug 28 2025, 7:03 AM

c-po changed the task status from Open to In progress.

c-po claimed this task.

c-po triaged this task as Normal priority.

c-po updated the task description. (Show Details)Aug 28 2025, 7:07 AM

c-po updated the task description. (Show Details)Aug 28 2025, 7:23 AM

https://github.com/vyos/vyos-1x/pull/4684

Quick note on this. It'll maintain the existing AS-Path in the advertisements, but it COULD change the behavior of route rejection on received routes.

This will create an internal array of local-as' with a single ASN ('100'):

router bgp 100
 neighbor 1.1.1.1 remote 200

And this will create an internal array of local-as' with both ASNs ('100', '150')

router bgp 150
 neighbor 1.1.1.1 remote 200
 neighbor 1.1.1.1 local-as 100 no-prepend replace-as

The advertised route will have the exact same AS-Path, but in the first instance (the current behavior), NLRI with AS150 would be accepted when received, and only would be rejected if it had AS100 in it. But in the second instance, it would drop NLRI with either AS100 or AS150

So if currently the CE has AS150 within their network, the existing config COULD allow the prefix to be accepted, but the change would reject those prefixes, requiring allowas-in or some other measure.

NOTE: Notice the emphasis on COULD. This is the behavior of Cisco routers, which obviously don't allow a per-VRF system-as. I'm not sure of the behavior of FRR when the global system-as and the per-VRF system-as differ. That internal array may still have both the global and per-VRF system-as' already, but if they keep a per-instance array, it could change behavior. Just thought I should mention this just in case.

Vijayakumar mentioned this in T7768: Message text (minor) issue in unused import workflow.Aug 31 2025, 7:08 PM

@c-po

! In T7760#233813, @L0crian wrote:
Quick note on this. It'll maintain the existing AS-Path in the advertisements, but it COULD change the behavior of route rejection on received routes.

Update on my above comment. I got some time to do a quick lab to see how this will behave, and I confirmed that the behavior does differ with a per-VRF system-as vice using local-as.

Below are some results from the lab.

Lab Details:

VyOS global system-as: 65400
VyOS VRF Test AS: 65000
Cisco Router AS: 65400

Downstream (Cisco Router):

router bgp 65001
 network 10.5.5.5 mask 255.255.255.255
 neighbor 10.1.2.1 remote-as 65000
 neighbor 10.1.2.1 route-map test out
!
route-map test permit 10 
 set as-path prepend 65400

VyOS VRF uses a different system-as than the global system-as. The prefix from the downstream peer is allowed to be received on VyOS with the global system-as (65400) in the as-path:

set protocols bgp neighbor 172.16.0.2 address-family ipv4-unicast nexthop-self
set protocols bgp neighbor 172.16.0.2 remote-as '65400'
set protocols bgp system-as '65400'

set vrf name test protocols bgp neighbor 10.1.2.2 address-family ipv4-unicast
set vrf name test protocols bgp neighbor 10.1.2.2 remote-as '65001'
set vrf name test protocols bgp system-as '65000'

vyos@PE2:~$ show bgp vrf test ipv4
BGP table version is 2, local router ID is 10.1.2.1, vrf id 6
Default local pref 100, local AS 65000

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.5.5.5/32      10.1.2.2                 0             0 65001 65400 i

VyOS VRF uses the same system-as as the global system-as; uses local-as to define a different AS to peer with. Routes received with the global system-as are dropped due to as-path restrictions:

set protocols bgp neighbor 172.16.0.2 address-family ipv4-unicast nexthop-self
set protocols bgp neighbor 172.16.0.2 remote-as '65400'
set protocols bgp system-as '65400'

set vrf name test protocols bgp neighbor 10.1.2.2 address-family ipv4-unicast
set vrf name test protocols bgp neighbor 10.1.2.2 local-as 65000 no-prepend replace-as
set vrf name test protocols bgp neighbor 10.1.2.2 remote-as '65001'
set vrf name test protocols bgp system-as '65400'

vyos@PE2:~$ show bgp vrf test ipv4
No BGP prefixes displayed, 0 exist

Turning on debugging for updates:
Sep 03 13:06:37 bgpd[2152]: [RZMGQ-A03CG] 10.1.2.2(Unknown) rcvd UPDATE about 10.5.5.5/32 IPv4 unicast -- DENIED due to: as-path contains our own AS;

So the changes proposed would cause the BGP behavior to change after an upgrade to a version using this change. Leading to traffic disruptions, or even outages if critical prefixes are rejected.

c-po mentioned this in rVYOSONEX85fe32f0e1a9: bgp: T7760: remove per vrf instance system-as node.Sep 23 2025, 3:01 PM

c-po mentioned this in rVYOSONEXd871fe9c4c65: bgp: T7760: deprecate per bgp vrf instance system-as node.

Restricted Repository Identity mentioned this in rVYOSONEXbf1c29aa7198: Merge pull request #4684 from c-po/bgp-vrf-system-as.Sep 23 2025, 3:01 PM

c-po moved this task from Need Triage to Completed on the VyOS Rolling board.Sep 23 2025, 7:04 PM

c-po moved this task from Open to Finished on the VyOS 1.5 Circinus (1.5-stream-2025-Q3) board.Sep 25 2025, 2:06 PM

c-po mentioned this in rVYOSONEX3f8404ac78e1: migrator: T7760: remove debug print statement.Sep 27 2025, 6:54 AM

c-po mentioned this in rVYOSONEX7da3fcc9b730: bgp: T7760: improfe verify() logic on default VRF removal.

c-po closed this task as Resolved.Oct 2 2025, 3:27 PM

c-po moved this task from Backlog to Finished on the VyOS 1.4 Sagitta (1.4.4) board.

fabrizziop mentioned this in T7904: BGP route reflector configuration broken due to T7760.Oct 3 2025, 8:57 AM

Viacheslav added a subtask: T7904: BGP route reflector configuration broken due to T7760.Oct 3 2025, 11:55 AM

Reverts due to the bug T7904
PR https://github.com/vyos/vyos-1x/pull/4776