Page MenuHomeVyOS Platform

VTI interface and BGP update-source bug
Closed, WontfixPublic


interfaces {
  vti vti3 {

protocols {
  bgp 65000 {
    neighbor {
      remote-as 65000

The BGP configuration doesn't survive a reboot.

I've found the following error in /var/log/vyatta/vyatta-commit.log:

[ protocols bgp 65000 neighbor update-source ]
IP address does not exist on this system
[[protocol bgp 65000]] failed
Commit failed

After removing "update-source" the BGP configuration survives the reboot.

So it seems the BGP configuration is being loaded before loading the vti interface.

Can someone help me to fix this bug?


Difficulty level
Easy (less than an hour)

Event Timeline

syncer triaged this task as Normal priority.Jun 8 2016, 4:43 PM
syncer added a subscriber: syncer.

can you provide version of VyOS
Also, can you confirm that it's reproducible on latest beta?

syncer edited subscribers, added: VyOS 1.1.x; removed: syncer.

It's still the same on the latest beta.

syncer changed the edit policy from "Public (No Login Required)" to "Custom Policy".Aug 21 2017, 2:00 AM
syncer edited projects, added VyOS 1.1.x (1.1.8), VyOS 1.2 Crux; removed VyOS 1.1.x.
syncer set Version to -.
syncer edited subscribers, added: Maintainers; removed: VyOS 1.1.x.
syncer added subscribers: UnicronNL, dmbaturin.

@dmbaturin @UnicronNL
any idea why this can happen,
as per report both current and stable affected

BGP configuration is definitely loaded after VTI configuration is loaded.

# /opt/vyatta/sbin/ | egrep -e '(bgp|vti)'
381 interfaces/vti
382 interfaces/vti/node.tag/mtu
730 protocols/bgp
901 interfaces/vti/node.tag/firewall
901 interfaces/vti/node.tag/ip
901 interfaces/vti/node.tag/ipv6
901 interfaces/vti/node.tag/redirect
901 interfaces/vti/node.tag/traffic-policy

I suppose the issue may be in that in case of VTI, the time configuration is loaded and the time the interface goes up. The simplest workaround is indeed to not use a non-permanent interface as update source (which I think is not exactly a good idea in any case), but...

I've tested setting BGP update source to a non-assigned address. It looks like the session doesn't get up on its own until reset (though this may need more testing), but it doesn't have any really negative consequences for the system either. In any case a non-functional session is better than loss of config parts.

I suppose I'm making this a warning rather than a commit-time error.