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.

I have investigated this a bit. Most operations for ports are doing one-by-one. Deleting as I see is always done in this way. Adding a range is done by a single command, but checking ports are doing one-by-one.
If we skip/change mentioned checking for adding ports, this should decrease initial commit time. But when we try to change/delete ports, the issue will back.
I think that there should be better to reimplement the whole firewall group section in Python, instead of fixing this logic now.

To track similar https://github.com/FRRouting/frr/issues/4471

My main question is why is this message displayed and do we need to worry.

I have had the maximum-paths setting for years since Vyos 1.1.x and I have a lot of routes ipv4 and ipv6 installed in the routing table with 2 or 3 routes even if they are not the same. I am not specifically using ecmp I just have multiple routes for fast failover.

For the ECMP it's necessary that as-path length, weight, localpref, med, etc were the same.
Only, in that case, more than one eq route will be installed in the routing table.

I have the following:
set protocols bgp as maximum-paths ebgp '3'
set protocols bgp as maximum-paths ibgp '3'

@Merijn If you don't use ECMP, only one best route will be installed in routing table.
In your case, the best path via 20562 6830 198611 with localpref 140.
In the bgp table, all prefixes will be present.
It's a general BGP Best Path Selection Algorithm.
The same is true for ipv4.

After receiving
zebra[1507]: 0:2804:fa0:8000::/33: Route install failed

How about parallel loops?
https://metacpan.org/pod/Parallel::Loops

Works properly on VyOS 1.2.5-epa1 (FRRouting 7.2-20200121-02-g031c58) and 1.3-rolling-202003130217(FRRouting 7.3)

Thanks @jestabro , works well with this change. After passing all the tests, I will write docs about VyOS in container.

@Dmitry The simplest workaround for the moment is to add the following to your load steps:

I've tracked this down to a bug in libboost-filesystem, versions < 1.56, that occurs if the locale is not properly set, as is the case within the Docker environment: