It was fixed in the rolling T2573
https://phabricator.vyos.net/rVYOSONEXf812c5d1ce01efa8323bfb797c57f68f474665bb

@Robot82
It will be by default in the new BGP implementation.
https://github.com/vyos/vyos-1x/blob/current/data/templates/frr/bgp.frr.tmpl#L5

Proposed CLI

reset mpls ldp neighbor x.x.x.x

PR https://github.com/vyos/vyos-1x/pull/571

awesome, thanks!

https://forum.vyos.io/t/limit-bandwith-for-indivindual-ips-on-1-2-5/5947/30?u=s.lorente

Also submitted PR for FRR 7.3 series https://github.com/FRRouting/frr/pull/7318

OK, thank you. I will test this. This should probably be made as default.

@runar The preliminary integration of tinc is basically completed, please see

Yes, both clients configured as DHCP clients.
Client 1 - eth0 - 50:00:00:06:00:00
Client 2 - eth0 - 50:00:00:07:00:00

This has come up multiple times before, see https://phabricator.vyos.net/T1698 for the solution.

I can confirm.
It happens after update procedure.

If I do a clean install of 1.2.6-s1 from iso, the rollback works fine.
If deploy from a qcow2 image, I see a similar error.

I should add that building the package on arm64 hardware (pi3/4) works fine. Building in the docker container fails.

Just my thoughts - there are situations where rp_filter is not sufficient, and it was not clear to me how to do this cleanly with the zone firewall, so I ended up hacking a few iptables commands in rc.local instead.

the issue is verified by soxrok2122 by using a stock ubuntu 20 host with the stock vyos/vyos-build:current-arm64 docker image

I'm reopening this issue as this seams to still be an issue. reported by user soxrok2212 on slack (#vyos-on-arm64)

It seems Client1 and Client2 only DHCP-clients.

Could you share also Client1 and Client2 configuration? Would be nice adding this lab setup to the docs

Please share your OpenVPN config

I think we could generate private/public keys using openssl instead of using the tinc utility to generate it... But i have not tested it

I am implementing tinc, but there is a problem I haven't figured out. Normally, in order for tinc to run, it must have a public key and a private key, and it happens that there will be a prompt for this generation command (ask where to save, etc), and it happens that the public key of the local node in the hosts directory is usually used together with some host configuration options. Is there a better way to implement it?

PR: https://github.com/vyos/vyos-1x/pull/569

This bug seems to be worse than I thought.
Here's an example:
On reboot an openvpn client inteface will come up outside the vrf. Any routes that get pushed by the server will not get added to the client because it's wants to add the routes inside the vrf of the vtun interface - but the vtun isn't a member.
Heres a log snippet:

PR for CRUX https://github.com/vyos/vyos-1x/pull/568

You're right, if-up.d scripts only get run for the interfaces defined in /etc/network/interfaces.

PR with increasing validator values https://github.com/vyos/vyos-1x/pull/566

I wrote a preliminary CLI configuration file rule. This is the first step in tinc implementation. For details, please read: https://github.com/jack9603301/vyos-1x/blob/T766/interface-definitions/interfaces-tinc.xml.in

The last thing I think we can add is the dual stack capability options. We only got 2.

Ok, so here's the import LDP FEC one that I think we could take advantage of as well.

I'd suggest:
set system syslog host 10.0.3.2 format 5424 - description stating this uses RFC5424 style format
set system syslog host 10.0.3.2 format ocetet-counted - description stating messages are octet counted

Ok, so here's the export LDP FEC one that I think we could take advantage of.

It seems to be working now, for some reason it didn't work when I first tried, but now it seems OK.

The one after that I feel would be fairly easy to also implement is customized label allocation. Again, it is under the family of IPv4 or IPv6.

The next one that I think would be fairly easy to add would be the following:

Hello sir. I am unsure if you're able to add more under LDP but I have found others if you possibly could add. They should be simple additions and are already supported under FRR 7.3.1.

I can't reproduce it in the latest rolling

placing the tinc deb in vyos-build/packages is appropriate while writing support for tinc, but for building on a production iso that is distribute it is not appropriate.. but it's quite easy to add the package to our own repository if we need that...

Another option is to compile and package by yourself, but the location of the repository is the problem

The version of tinc vpn supplied with buster is 1.0.35, and 1.1-pre17 is only availabe in the experimental repository as for now. The first release of 1.1pre is from 2011 and i would say that it is quite mature at this point.

I don't think it's necessary to compile DEB packages because they can be obtained directly from apt

ATS looks nice.

@c-po , it looks like the wrong CLI definition, we can increase the limit in XML.

@Dmitry is this a limitation of Accel-PPP or can we increase the limits on the CLI?

I can feel that pain! When looking at the source from VyOS 1.2 (crux) it looks like it always behaved in this way.

Please post at forum.vyos.io for support

@christophedc0 Have you enabled NAT rule logging?