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

This PR should built proper images

This has a dependency on python3-flask-restx, which will need to be added using, for example, T2396.

https://vincent.bernat.ch/en/blog/2017-ipv6-route-lookup-linux

Marek Isalski Today at 6:31 PM

We've got full IPv4 and IPv6 routing tables on our VyOS boxes, and we *definitely* needed to increase net.ipv6.route.max_size (we picked 256k to give us some headroom).

Some statistics from ipv6 bgp summary

@thomas-mangin the sessions are still stable, for 7 days now. The only thing changed was that max_size limit. Also no packetloss on the IPv6 connections has been observed during this time.

@Merjin is trying this:

sudo sysctl -w net.ipv6.route.max_size=131072

https://serverfault.com/questions/902161/linux-host-randomly-stops-answering-ipv6-neighbor-solicitation-requests
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115

any L2/L3 issue affecting TCP between the BGP speaker will cause this message. Looking forward to a TCP dump of the traffic when it occurs.

@syncer Re-opening this. Had the first exact same incident on a different router with an IPv6 BGP session on a RJ45 connection, so that would rule out any issues with the Intel X710 card in relation to this issue.

We ave no RPKI filtering active yet, so https://github.com/FRRouting/frr/issues/5458 seems not related.

I have made pull request in https://github.com/vyos/vyos-1x/pull/352, please help to review it.

I have made pull request in github, please help to reviw it: https://github.com/vyos/vyos-cloud-init/pull/8

This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved

This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved

I can confirm this bug, also exist in 1.2.5 OVA

Hypervisor is VMware ESXi. I believe these were installed from OVA several
months ago, but haven't reproduced recently.

Is 1.2.3 was deployed from OVA or install from ISO?
Which hypervisor?

Found that in drivers 2.3.6 and newer this should also work:

Note: will be good to disable this by udev rule for i40e

Upgraded the firmware of the X710 adapters from 6.0 to 6.8, waiting for Dell to get 7.0 and 7.2 ready. But for now the sessions are 18 hours stable so little optimistic that it was a firmware issue and not BGPd causing issues

There are no other reports about such issues
we need valid reproduction procedure for this, otherwise, not much that we can do

PR https://github.com/vyos/vyatta-netflow/pull/5

@Dmitry
set system flow-accounting interface 'eth4.XX'
set system flow-accounting interface 'eth4.XX'
set system flow-accounting sflow agent-address 'xxx.xxx.169.246'
set system flow-accounting sflow sampling-rate '2048'
set system flow-accounting sflow server xxxxx.tld port '6343'

@blackmetal provide, please flow accounting configuration show configuration commands | strip-private | match flow for reproducing

T2199 for the firewall rewrite - free for the taking. I wouldn't stray much from the old code logic, as some things have hidden meanings. Especially leaving checks out could introduce bugs unless you're absolutely sure they can be bypassed.