@marekm
Can you check your BGP configuration if "router-id" is declared?
Also, what is with interface names?

ppp-lot29
ppp-jmg22
ppp-rol81
ppp-rod8

Do you use scripts with renaming? How to reproduce it?

/usr/libexec/vyos/op_mode/version.py:
Built on: Thu 13 Aug 2020 11:57 UTC

Happens also when just using the booted image without install. Investigating.

It crashed again after 5 days in 1.2.6-epa1, in the same function, also when a dynamic PPPoE interface was deleted.
It happens less frequently after the former customers who repeatedly failed authentication have been physically disconnected.
Again, BGP no longer works after watchfrr has restarted the bgpd process. All works again after reboot.

Is probably fixed in https://phabricator.vyos.net/T1291 according to cpo on slack

Maybe related - https://github.com/FRRouting/frr/issues/6439

This happens only when in config before migration exists nodes system 'ntp' without other params.

Fixed int the latest rolling, VyOS 1.3-rolling-202008110118

I am giving up with HFSC. I have been studying it for a long time, I have tested it in many different ways, without VyOS too. The only thing I have found is that this is is not a problem of VyOS.

related to T1699

@Merijn Have such problems been repeated?

The issue did not reproduce neither in 1.2.5 nor in 1.3 version.
Try in the new release and re-open the ticket if any new information appeared.

@olofl I can't confirm this bug int the 1.2.5 LTS version.

I can't confirm this bug.

vyos@vyos# set vpn ipsec ike-group IKEv2_DEFAULT mobike disable 
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# run show version 
Version:          VyOS 1.2.5
Built by:         Sentrium S.L.
Built on:         Sun 12 Apr 2020 15:18 UTC
Build UUID:       1695c660-d785-4b16-a54b-66d6a02ea24f
Build Commit ID:  48cc9fc46569e6

I thought the problem could be related to VyOS, but now I have found the same behavior when using directly tc hfsc.

show interfaces vrrp

I have tried the above scenario in the VyOS 1.3-rolling-202007200117 which is the latest version and the issue did not reproduce. So I would request you to try in the latest version and share your feedback.

https://github.com/vyos/vyatta-cfg-vpn/pull/34

Can confirm that the image now contains wireguard.ko.

Understood, will re-check and close the report once confirmed.

@linuxgemini we do not support DKMS.

Did a rebuild and found the silent error:

While I was checking my old build, I have seen this on /live/filesystem.packages:

This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.

Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.

Ok, nice. And how about 1.2? Is it possible to fix this with the 1.2.6 release?

This is already fixed in 1.3

The user-data dir actually is preserved on upgrade, it's just the check that is faulty. Need to look into it.

It looks like this bug is in the kernel.
1.2.5 - 4.19.106-amd64

No, seems to be fixed! I was pretty sure it was upstream, must be resolved now.

Could anyone test if it's still reproducible?

When googling on the error given, T109 shows up where I had posted about this in 2018. I'm not sure it's related to this. Im not sure any configuration has been lost on reboot.

https://phabricator.vyos.net/T1564

Also in 1.2.5

vyos@vyos:~$ show protocols bfd peer 10.203.42.1 
% Unknown command: show bfd     peer 10.203.42.1 local-address 10.203.42.254 vrf default
vyos@vyos:~$ 
vyos@vyos:~$ show protocols bfd peer 10.203.42.1 counters 
% Unknown command: show bfd     peer 10.203.42.1 local-address 10.203.42.254 vrf default counters
vyos@vyos:~$ 
vyos@vyos:~$ 
vyos@vyos:~$ show version 
Version:          VyOS 1.2.5

I did some tests and the only problem appears when adding a route-map to ipv6.

@lawrencepan your configuration not committed because,

1. "route-reflector-client" can be used only when remote-as and local-as are equal

Try to check your commit.
You wiil see

PR for 1.2: https://github.com/vyos/vyatta-cfg-system/pull/124

PR https://github.com/vyos/vyatta-cfg-quagga/pull/48
Also added the second commit which fixes the path to zebra daemon

BGP Router ASN 65001 .
PeerGroup ipv4 & ipv6 ASN65002

Hello @lawrencepan , can you explain, why you need different AS for route-reflector-client?
Can you add your route-maps ROUTE-V4 and 'ROUTER-V6?

@jjakob, yes, thank you.
PR for 1.3: https://github.com/vyos/vyos-1x/pull/434
I will summit PR for 1.2 once 1.3 is released and tested.

Just to confirm, increasing the route,max_size fixed this issue completely. I think it can be closed. But maybe we should set these settings by default before closing this.

I think the way to do this is in src/conf-mode/interfaces-ethernet.py in apply(), don't change the interfaces mac if eth['is_bond_member'] is set.

@runar, thanks for clarification! I will change the initial description accordingly.

To clarify the hw-id tag. This is the only way VyOS scripts know what interface to give what name on bootup, as the boot-order of nics could be different on every reboot (potentially) vyos needs a way to identify the "correct" order of the nics when it boots. if you remove the hw-id tag from the interface the configuration script don't know what interface to give the configuration to, so you could potentially get nic-reordering on every single reboot.

https://github.com/vyos/vyos-cloud-init/pull/10